Why Continuations Are Coming to Java - <AUTHOR> https://www.infoq.com/presentations/continuations-java/ <comment><USER3> > I serve as a technical lead for Project Loon. That is the project that's > intended to add continuations and fibers to the JDK.

> However, actually, Project Loom, the goal of the project is to add > continuations, fibers, and tail call elimination.

I'm guessing that the project is called either Loom or Loon (and i believe it's the former), but i like the idea that there are actually two cooperating projects, each of which occasionally suspends and lets the other run.

<comment><USER4> It's probably Loom. It's thematically connected to "fibers" and doesn't make the immediate statement that you think your own project is doomed. Neither of those is true of Loon.

<comment><USER3> Doesn't seem to have slowed the Canadians down much:

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

</comment></comment></comment><comment><USER5> Honest question, maybe obvious: Why is the java-scheduler/ thread model so much better than the OS-level one? What does the java one do, or better what does it not do? And why can't the principles which make java-scheduling fast be applied to OS-threads?

<comment><USER6> There are a couple of issues here: scheduling, and managing the stack. The reason a runtime can do better than the kernel is that its constraints are (hopefully) less constraining than those of the kernel.

In the case of managing the stack, the kernel must be able to support languages like C/C++ and Rust, that can have internal pointers pointing into the stack itself. This makes it hard to reallocate stacks dynamically and move them around in memory. The JVM doesn't allow such pointers in application code, and internal bookkeeping pointers are known.

As to the scheduler, the kernel must support very different kinds of threads: threads that serve server transactions that block very often, and threads that, say, encode a video, that rarely block at all. These different kinds of threads are best served by different schedulers (e.g. the "frequently blocking" kind of thread is best served by a work-stealing scheduler, but that may not be the best scheduler for other kinds of threads). When you implement fibers in the runtime, you can let the developer choose a scheduler for their needs.

<comment><USER7> That sounds like the runtime has more constraints thus it can make more assumptions, not less constraints, while the OS one must be more general.

<comment><USER8> It depends on your perspective.

The OS one has more _requirements_ (the number of "it must do..." is much higher), which constrains it's design space much more. I think you can call that as "having more constraints" because it must meet more needs to be even viable as a solution.

The number of requirements for JVM threads is much lower, thus less constraining, allowing it more freedom to implement solutions that can meet its narrower window of features.

</comment></comment></comment></comment><comment><USER9> Ron Pressler!? Isn't that our very own 'pron'?

<comment><USER10> You should see him go on /r/java!

I'm kidding, his posts are awesome :)

<comment><USER11> > You should see him go on /r/java!

Yeah, if just someone had banned him, we could have had Loom by now.

Just kidding as well... great work pron

</comment></comment></comment><comment><USER12> The Project Loom webpage: [https://wiki.openjdk.java.net/display/loom/Main](https://wiki.openjdk.java.net/display/loom/Main)

</comment><comment><USER13> We had a weird network issue in a production system, and because the interplay of different components was very difficult to debug I briefly investigated each component. This lead me to run Jersey (a JAX-RS implementation, ie. a REST library) with a debugger.

Jersey is written in a continuation passing style. That's the only time I've seen the style outside academic discussions of Scheme. I found the code flow difficult to grok and thought continuation passing didn't fit Java very well. That may all be just due to my lack of experience, though.

Granted, the alternatives to handling concurrency each have their own problems. Maybe this is a good idea; it will be interesting to see in practice.

<comment><USER14> Having native access to continuation control lets you avoid writing in continuation passing style. It's common to implement native continuation control with a compiler pass that automatically converts code into continuation passing style. (Similar to how you would transpile async/await in JavaScript.)

</comment></comment><comment><USER15> Wow, continuations are pretty awesome, because with them you can build any control structure you like. Now if Java only had macros, so that homegrown control structures could be concise & succinct, like built-ins …

It's kinda of funny how languages are slowly becoming more and more Lisp-like — even Lisp is available, still offering what it offers.

As an aside: argh, in Firefox it stole the spacebar, so there's no way to scroll down the page, even if I click outside of the video.

Why do web pages do that?

</comment><comment><USER16> Lack of Continuations / coroutines has been a huge pain in my rump for a while now; it is fantastic that they're finally adding support for it.

</comment><comment><USER17> Is tail call elimination the same as tail call optimization? I know that schemes use this to keep the stack from blowing up during recursive function calls, and that currently the JVM, and by extension Clojure is not able to handle this.

I also remember reading somewhere that this wasn't possible to add/not on the road map for the JVM. Does project Loom change this?

<comment> dan-robertson Yesish.

The way I read it, tail call elimination is the guaranteed application of tail call optimisation with a well defined meaning of what a tail call is. Eg scheme requires TCE.

Tail call optimisation is a transformation a compiler may choose to do to make code that looks like "return foo(...)" run faster. A compiler may choose to not do it because it might not be implemented or faster or it could make debugging harder. There is no guarantee it will happen.

TCO makes some code faster. TCE allows one to write different looking programs knowing they won't blow up the stack.

This all being said I think most people mean what I have referred to as TCE when they say TCO.

</comment></comment><comment><USER18> Seems like every sufficiently advanced language at one time or another turns into LISP.

<comment><USER19> "Invited Talk - Guy Steele" at ClojureTV.

 _We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp._

</comment></comment><comment><USER20> The question is not why, but when. When?

Our server has long waiting http handlers, which occupy java threads while waiting, thus limiting the server throughput to the number of threads java can maintain, and I'm holding off a rewrite on async servlets for several years already to avoid complicating the code, because I hope cheap threads (fibers) will become available, but there is no timeline for Loom. When can we hope it will be released?

<comment><USER21> Maybe with kotlin coroutines you can rewrite the application partially. Is there a difference between that and fibers?

<comment><USER20> Kotlin coroutines, as well as js and c# async/await, require us to change declaration of calling function. We can call a "suspend" function only from a "suspend" function, which in turn can only be called by another "suspend" function. So if I change some of my functions to "suspend" everyone upper in the call stack should be changed to "suspend", which is not always possible because that may be a 3rd party code.

That's not necesserily a deal breaker, but that's the difference.

For Java there is Quasar lib, which introduces async/await through bytecode instrumentation. It's by the same authors who work on the project Loom currently.

I don't use it because: a) the project web site feels a bit abandoned; I guess they concentrate on Loom now 2) I need analogues of wait/notify, sychronized, etc which are used in this code and not provided by Quasar; Quasar only provides lower-level primitives. One either need to implement such constructs on top of Quasar, or reimplement the logic. So it's not a drop-in replacement.

The project Loom aims to be mostly a drop-in, in particular fibers will support synchronized, wait/notify, etc.

<comment><USER22> Quasar was created by the same guy (Ron Pressler) that is the tech lead for Project Loom. The reason Quasar feels a bit abandoned is because he's bringing the thinking right into the JVM.

</comment></comment></comment></comment><comment><USER23> Because Java eventually implements everything that was done years ago in Smalltalk. Despite some having said it was unnecessary back then. Also, expect that a feature that was implemented in Smalltalk by a single dev as a library (this applies to continuations) will take a small team in Java. (Though the Java implementation may well be more robust and faster than the Smalltalk one from years ago.)

</comment><comment><USER24> The bits about multi-node computation reminds me of Racket's Places [0]. Have any other mainstream languages (Racket doesn't count) tried this technique before?

[0] [https://docs.racket-lang.org/distributed- places/index.html](https://docs.racket-lang.org/distributed-places/index.html)

<comment><USER8> On its face, sounds like Erlang/OTP.

<comment><USER24> Ah duh! Good catch.

</comment></comment></comment><comment><USER25> 30min in and I think:

Are they now trying to make Java to work like PL/SQL, Cobol, SAP (ABAP = SQL+COBOL)..?

I think it is a good idea, and is a way to bridge the gaps between the old and "new" way of writing programs. The real reason is not just scalability but traceability, that you can change code at runtime, closer connected to the database..

</comment><comment><USER26> What ever happened with continuations in Scala? A lot of people were excited about them back in 2009, but if I google them now I still only get pages from 10 years ago. I haven't used Scala in a very long time, so I stopped paying attention to any changes in the language.

<comment><USER27> as far as I can tell scala concurrency basically boils down to a few different subclasses that have some overlap: 1\. streaming/observable focused like Monix 2\. IO effect type like Cats Effect and ZIO 3\. Twitter futures/Stdlib futures which are different from each other in some crucial ways

<comment><USER28> Probably need to add 4. Akka.

</comment></comment></comment><comment><USER29> Apache Commons Javaflow is an early implementation of continuations: [https://commons.apache.org/sandbox/commons- javaflow/tutorial...](https://commons.apache.org/sandbox/commons- javaflow/tutorial.html)

<comment><USER30> I vaguely seem to recall that Rhino, Cocoon's pre-Node serverside javascript, had continuations too. That much have been around 2006 or thereabouts.

<comment><USER31> I remember them too. I had to dig a little to find the links I remember from the past.

[http://web.archive.org/web/20190127111220/https://wiki.apach...](http://web.archive.org/web/20190127111220/https://wiki.apache.org/cocoon/RhinoWithContinuations)

From the Rhino Google group, it looks like some people are still using continuations in Rhino:

[https://groups.google.com/forum/#!topic/mozilla-rhino/Gfo- dO...](https://groups.google.com/forum/#!topic/mozilla-rhino/Gfo-dOzQXCw)

[https://github.com/szegedi/spring-web- jsflow](https://github.com/szegedi/spring-web-jsflow)

<comment><USER32> That Rhino js engine stuff was all written in Java too.

</comment></comment></comment></comment><comment><USER33> In the talk he says that continuations compose much better than monads. Can someone elaborate on this?

<comment><USER34> Monads don't compose, in the sense that if you two monads of different types you can't always mash them together to create a single monad that encompasses both of the effect the two monads represent. This is not surprising as (side-)effects don't in general compose so there is no reason that monads should.

Now I disagree with Ron's assertion that continuations compose better than monads. Here's why:

All monads can be expressed in terms of the continuation monad. As the name suggests this is just a monadic encoding of continuations. (See [https://www.schoolofhaskell.com/school/to-infinity-and- beyon...](https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick- of-the-week/the-mother-of-all-monads)).

If your language has continuations built-in then all programs are effectively running in some "ambient" monad that can express all other monads. Just like if you have exceptions you're effectively running within an error-handling monad.

So essentially rather than writing `F A` (or `F[A]` or `F<A>` or whatever syntax your language supports) to represent effectful programs all programs are implicitly running within such an effect type.

<comment><USER6> It's true that monads and delimited continuations are equivalent, but what we have here aren't any delimited continuations but what's known as _multi- prompt_ delimited continuations, and I call them "scoped continuations" ([http://blog.paralleluniverse.co/2015/08/07/scoped- continuati...](http://blog.paralleluniverse.co/2015/08/07/scoped- continuations/)). Those compose well, and their pure-FP counterpart is algebraic effect systems (based on monads, but don't use monad transformers).

</comment></comment></comment><comment><USER35> What impact, if any, would this have on Clojure?

<comment><USER36> I had a discussion about this with some other folks recently.

Clojure already supports forms of delimited continuations. You can use core.async for example, or cloroutine. That said, it can't yield across stack frames. One problem with that is that if you use a go block for example, calling anything inside it which will block can sabotage your go thread. With Project Loom, all blocking call made within a Fiber will yield it instead of blocking the thread. That would be the big advantage, and possibly something Clojure could leverage as well, so that say making a blocking IO call even indirectly inside a go block would park instead of blocking.

</comment></comment><comment><USER37> anybody get this feeling that all languages are converging to a similar core set ?

<comment><USER38> All languages are becoming Lisp, except for the added challenge of avoiding parentheses.

<comment><USER19> Dylan did it first though.

<comment><USER39> Modula-2 had coroutines!

<comment><USER19> Indeed, but I was replying to _" All languages are becoming Lisp, except for the added challenge of avoiding parentheses."_.

Now if we are speaking about coroutines, there are other languages even older than Modula-2, although it was probably the most mainstream one at its peak.

</comment></comment></comment></comment></comment><comment><USER40> Does anyone have a good link to the state of the modern thinking on continuations?

I remember from back in the Scheme R5RS era there was a conflict between call/cc and dynamic-wind.

If you have a dynamic extent (like for example a try {} finally {} block that does resource allocation/deallocation), and you exit, but then jump back into the block, how far do you try to re-wind the state? You probably don't re-open files, but you would probably want to re-set any dynamic-scoped variables.

I don't remember seeing this raised as an issue recently, so it must have been solved somehow, and I'm just wondering how.

<comment><USER41> Dynamic-wind was created to tame call/cc and exceptions, rather than being in conflict with it. It directly provides the facilities for re-re-setting things when you re-enter a left scope.

However, you might want to look up delimited continuations as a different approach to similar kinds of control flow.

<comment><USER40> Yes, thank you. I was thinking of Kent Pitman's critique that unwind-protect didn't have the right semantics when implemented with dynamic-wind, and that (in general) it seemed like fluid-let and unwind-protect wanted different sorts of continuations to implement them. (And now I need to go read more about one-shot vs multi and delimited continuations.)

Someone (I forget who) had a critique about dynamic-wind itself that (IIRC) involved capturing continuations from within the before- and after-thunks of dynamic-wind, but that seems more like an edge case.

</comment></comment></comment><comment><USER42> How will ThreadLocal behave under different fiber context switches?

<comment><USER6> A fiber will appear to be a thread. You can even call Thread.currentThread and get a consistent Thread object representing the fiber. This is done so that as much existing code as possible would be able to run, unchanged, in fibers. We _may_ (or may not), however, introduce newer, better constructs that new code will be encouraged to use.

<comment><USER42> Oooo cool! It may be important or useful to include the 'old' contract elsewhere in the SDK.

</comment></comment></comment><comment><USER43> What is called continuations in Java is available as "coroutines" in Kotlin, today. Both terms means more or less the same, from a programmers point of view, actually Continuations are part of Kotlins coroutines.

[https://kotlinlang.org/docs/reference/coroutines- overview.ht...](https://kotlinlang.org/docs/reference/coroutines- overview.html)

<comment><USER44> Is there some special jvm/dalvik support for it?

<comment><USER45> It's a compiler plugin that generates bytecode for you, so there's no need for support from the runtime.

</comment></comment></comment><comment><USER46> How does this differ from scheme-style continuations? IIRC, full continuations in the scheme sense of the term are currently impossible in Java as they require forbidden stack manipulation. Or is what's being proposed here something entirely else?

<comment><USER47> We're adding delimited one-shot continuations to the JVM. The common public interface to these is likely to be fibers rather than raw continuations, as they are much easier to work with and allow the standard library and lots of existing code to take advantage of the new features with little to no change.

<comment><USER48> By one-shot you mean dynamically enforced, right? I.e. if you invoke it a second time it will raise an exception?

<comment><USER49> Not exactly, since they are using a fiber API instead of one built with raw continuations. In this context, being one-shot means that there is no operation for cloning or "forking" a fiber.

Each time you resume the execution of a fiber, it continues to execute until it reaches its next yield point. There is no way to go "back in time" and resume execution from a previous state of the fiber, which is what multishot coroutines or the fork system call would let you do.

</comment></comment></comment></comment><comment><USER50> So will fibers in the JVM be as fast, robust, and as cheap as processes in Erlang's BEAM?

</comment><comment><USER51> Here's a decent video with some code included: [https://www.youtube.com/watch?v=vbGbXUjlRyQ](https://www.youtube.com/watch?v=vbGbXUjlRyQ).

The intro music's a little weird for a dev con.

</comment><comment><USER52> One thing I get learning about implementing continuations is that at the end them have huge runtime cost and complicate implementation and debugging greatly.

Even do a simple interpreter with them quickly get out of control.

Exist update info in how tame it?

<comment><USER53> One approach, which Java is taking, is to implement a more structured form of continuation, rather than say the Scheme-style call/cc ones. A quote from the article: "To be more precise, if you're interested in the theory of continuations in the academic literature, the kind of continuation of this class implements are called one-shot multi prompt delimited continuations..."

<comment><USER52> That kind of continuation don't have much info that I remember and probably I'm not the only one:

[https://www.reddit.com/r/ProgrammingLanguages/comments/9r2kt...](https://www.reddit.com/r/ProgrammingLanguages/comments/9r2ktu/rain1_blog_are_first_class_continuations_a/)

but still look interesting if somehow manage to be performant-enough and tame enough. I think continuations are best for the internals of the compiler/vm than to surface to the end user...

</comment></comment></comment><comment><USER54> JAVA is threaded go down to the OS level and is relatively resource-expensive (RAM and context switching) so don't scale well. If you want to know more visit CETPA INFOTECH PVT LTD

</comment><comment><USER55> >if a continuation gets into an infinite loop, we can ask it to preempt itself, and forcefully remove it from the CPU.

This is interesting, any idea of how they can do it?

<comment><USER56> That's easy. All Java threads regularly pass through "safe points" where the runtime can choose to suspend them. Think about garbage collection - <USER2> runtime must be able to reliably and regularly pause threads so their stacks can be scanned. Whether interpreted or JIT compiled, there are ways to queue a piece of code 'into' a thread that's currently running and a short time later that code will execute. Safe points are used for many different things in HotSpot.

So whilst I haven't looked at the code, presumably continuations are pre- empted by forcing the host thread to a safepoint and then unmounting it.

Note that forced pre-emption + a scheduler + a userspace notion of a thread gives you the tiniest core of an operating system. The next big leap in operating system design is certainly language-generic virtual machines fused with the basics of an OS.

</comment></comment><comment><USER57> There's an error in the presentation's slides: The type of returnIO is "a → IO a" and not "IO a → IO a".

<comment><USER6> Correct. That was a typo that was then copied and pasted so the mistake appears twice.

</comment></comment><comment><USER58> About time. I definitely could use a yield keyword, if someone is reading this.

</comment><comment><USER59> So it's like python's yield statement aka generators?

<comment><USER60> It's more general than generators. You can create generators using it, and also other control flow constructs.

<comment><USER61> Yup, I did exactly that in Scheme

[http://billsix.github.io/bug#_make_generator](http://billsix.github.io/bug#_make_generator)

</comment></comment></comment><comment><USER62> I find it amusing that whenever people talk about Java, they're somehow using magic to describe it. It's like Java programmers see themselves as magicians...

This is especially widespread with spring boot. I've even read sentences like "It's hard to say what it does, you can only see it's effects!"

<comment><USER3> I wonder if it's because there is such a sharp line between what a Java programmer can do in Java, and what the JVM does to make that possible. Much of what the JVM does is impossible to even describe in normal Java. That line doesn't exist in, say, C++, where the compiler is just another C++ program.

With the caveat that there are JVMs written in Java, so that line can be crossed:

[https://www.jikesrvm.org/](https://www.jikesrvm.org/)

The same mechanism could apply at the Spring Boot boundary. Using Spring Boot (for simple applications) is easy enough. Implementing it takes code that is beyond bizarre.

<comment><USER63> The JVM is not magic, neither are Java programmers magicians, but I think the reason magical terms are used to describe Java systems is that the ecosystem had lots and lots of time to develop libraries and abstractions (a few of which happen to be of the right kind, read: leak just the right amount). Your typical Java programmer is well aware what it takes to implement a battle- proof connection pool, and will not attempt to implement their own. To them, adding the config stanza to enable a connection pool indeed feels like magic. Other platforms, that come with preconfigured connection pools, do not leak this to the programmer, and 80% of their users will not know what a connection pool is.

<comment> james-mcelwain The way I would phrase it is that the Java ecosystem is simultaneously both higher level and lower level (in terms of abstraction, not the machine) than many other platforms.

The ability to swap out basically any component of a framework like Spring simply by including a different dependency or replacing a bean at runtime allows for fine grained tuning that isn't possible in many other frameworks.

But this flexibility and/or modularity is enabled by a heap of pretty magical abstractions that glues everything together.

<comment><USER3> The Java library developer's aesthetic has traditionally been to make things possible, rather than to make things easy. So you may have to write a lot of code or config to get something to happen, but you will have a lot of control over what happens.

This is the opposite emphasis to, say, the Ruby community, which values a simple, lickable, surface interface with a large amount of opaque magic hiding behind it.

</comment></comment></comment></comment></comment><comment><USER64> Will this mean that Akka can support true multitasking like Erlang? If so, that sounds amazing. Being able to write blocking code in actors is such a big win.</comment>


Software Inventory by Joel Spolsky - <AUTHOR> http://www.joelonsoftware.com/items/2012/07/09.html <comment><USER2> Everything that Joel says is true, but keep in mind: having inventory or backlog has a cost, but everything that clears it also has a cost. Inventory is always bad, but sometimes it's less-bad than the alternatives.

Anecdata: My company has a client with a large budget and a large appetite for change on his website. The project manager intentionally chosen to throttle back the rate of change and build up a backlog. The intention is the rate of work is about enough to employ 4 people full-time, and we'd rather have that be consistent rather than just an average. Were he to clear the backlog as it came in, the flow of work would be very uneven, and that would necessitate all sorts of other overhead costs. During boomtimes, onboarding new people to the project; during busttimes, finding other work for the 4 current people; during the transitions between the two, juggling obligations from 2-3 projects as people get transfered from one project to another.

TL;DR project management is hard. Reducing inventory is a Good Thing and you should do it, but it has a cost, so don't be cargo-cultish about it.

<comment><USER3> To be fair, he said to do exactly what you said: cut the backlog off at X weeks. For something new to come in, something else has to go.

It was the bug db he recommended clearing out, which I kind of agree with. Little is more disheartening to a developer than seeing a project with 3000 bugs. You can't help think your project sucks, so why bother (or you learn to completely ignore the bug db).

Regardless, your last statement of "don't be cargo-cultish" always applies. Understand the tradeoffs for _your_ organization. Even Joel just called them "suggestions" not "here's how you do it".

<comment><USER4> "Little is more disheartening to a developer than seeing a project with 3000 bugs."

Try 100,000

I was slightly active as a tester for Ubuntu 12.04 (a long term release so things that did not make the UI and package freeze would be there for _years_ )

I noticed a lot of minor bugs being labelled 'won't fix', and I noticed a lot of 'down chain' bugs happening because of kernel/X server &c which automatically got sorted once the fixed packages made it in.

The whole thing was most educational to me (as an end user) and the result is rather nice.

<comment><USER3> That would be an interesting experiment. 100,000 bugs, the vast majority of which you have no control over; 3,000 bugs, the vast majority of which you have control over but aren't going to do anything about; or 100 bugs that you know you are going to quash.

I can see how the first two could be quite painful for developers, but they are also helpful for support reasons. "Yes, that annoying menu things has been reported and we just aren't going to get around to fixing it," seems better than a bug black hole that continually swallows everything customers/support tells it.

<comment><USER4> launchpad does that triage, they have people processing stuff most days. It was educational watching how the various freezes along the time line funnelled the bugs that would get fixed. This is an extreme example, a whole operating system with non-trivial packaging. Your phone app should be easier!

pyroom have a suggestions tracker... the thing is _meant_ to be minimal!

</comment></comment></comment></comment></comment><comment><USER5> One easy way to limit the size of the backlog is to let the community itself vote on which bugs and features you should be working on, then add a little editorial selection and take the top (n) to work on. That's what we do at Stack Exchange, anyway:

<http://meta.stackoverflow.com/?tab=bugs> <http://meta.stackoverflow.com/?tab=requests>

I find that the community appreciates being involved in these decisions, and often (but not always†) has good ideas of what you should be prioritizing and what issues are true pain points.

† [http://www.codinghorror.com/blog/2012/02/listen-to-your- comm...](http://www.codinghorror.com/blog/2012/02/listen-to-your-community- but-dont-let-them-tell-you-what-to-do.html)

<comment><USER6> True, although software can never be 100% user/customer/community driven. Something Henry Ford something something "faster horses." Or within my lifetime, if we had take a survey in 1983, how many personal computer users would have voted for "mouse and bitmapped screen" as their top priority?

<comment><USER5> I didn't say 100%, did I? Anyone pushing for 100% of anything is basically crazy.

Also, as for "faster horses", per this article "We have no evidence that Ford ever said those words."

[http://blogs.hbr.org/cs/2011/08/henry_ford_never_said_the_fa...](http://blogs.hbr.org/cs/2011/08/henry_ford_never_said_the_fast.html)

</comment></comment></comment><comment><USER6> Joel's 100% correct about limiting the size of the backlog. It doesn't matter whether you're using a kanban system, SRUM, a bug database, Github issues, whatever. The team's attention is a finite resource, and stuffing items in there wastes it.

Limiting the size forces you to throw items out as you go along, and each one of these "We're never going to do this" decision helps sharpen the design and prevent over-architecture.

<comment><USER7> I've had some personal success with acquiring a bit of a Zen attitude about bugs in the bug database stacking up, and just letting the good stuff float to the top, but this appears to be a very difficult attitude to cultivate, based on the fact almost nobody else seems to be able to do this. I've sometimes managed a middle ground where we create a state in the bug system for "Yes, acknowledged", which basically means nothing but allows those who get freaked out about 3000 bugs being "open" to make the bugs "not open" while not requiring the mental commitment to "close" the bugs. (Don't _tell_ them it means nothing! Of course in practice you are basically closing the bugs as "won't fix", but don't _tell_ your managers that.)

I suppose my metapoint is that there's a lot more psychology going on here than may meet the eye, and there's more than one way to not drown in the bugs of a basically-functional product.

<comment><USER8> Indeed, I prefer this approach to Joel's. Whether a giant bug list actually wastes any attention is a matter of attitude, terminology, and interface.

If the moldy oldy bugs collect _mostly_ out of view, but can be found when needed – for example when a similar bug is reported again, or an overlapping feature is being added – then this 'long tail' of bugs can be an asset rather than an inventory cost.

In fact, I would suggest any mental model that relies too much on the 'physical inventory' analogy can't possibly be making optimal use of the possibilities of digital technology. Bits are nearly free, interface is iteratively-malleable, and improving search offers instant only-when-needed access to arbitrarily large backlogs and historic records.

I understand that some meticulous personality types can find this approach disturbing – and these are personality types that are especially good software developers in many dimensions. This tension should be resolved with terminology and interface: let each team member see only the backlog that helps them allocate their attention.

There are parallels to the deletionist-vs-inclusionist split in wiki/reference communities. Joel is a bug-deletionist. I am a bug-inclusionist.

<comment><USER9> _Bits are nearly free, interface is iteratively-malleable, and improving search offers instant only-when-needed access to arbitrarily large backlogs…_

I am very suspicious of this argument, although I freely admit that my instincts are colored by my old company's use of Atlassian Jira. I was generally okay with Jira, at times when the backlog was under control, but if there's an issue tracker that can manage several thousand active entries without reducing you to tears, Jira is not it.

Bits are nearly free, but human attention is not. Human attention is even _smaller_ than a physical filing system.

Issue-tracker interfaces may in theory be "infinitely malleable" but that's a yak-shaving exercise waiting to happen. Every minute a team spends redesigning or reconfiguring the issue tracker is a minute they aren't spending working on the product. That's Spolsky's point.

Search? When there's _one_ issue in the backlog about the color of the toolbar then search will work great. But then the toolbar acquires a "color" palette. And then two years go by, during which people keep bikeshedding aspects of the toolbar. And then one day you'll search for "toolbar + color" and up will come fifty entries. Which you will probably have to read.

If you're a talented search jockey you can probably construct a better query to whittle down that SERP page, assuming your issue tracker has a Google- quality search backend, which it probably does not. But constructing fancy searches takes time and thought. And there's a garbage-in-garbage-out problem with search: If your issues aren't written with a sufficient level of detail, precision, care, and choice of terminology (and somehow they never are), your search won't distinguish them well. Reporting bugs well takes a lot of time and care. Writing carefully-described issue descriptions with a standard terminology takes time, even if you're a trained library scientist. And, again: All that time spent refining searches, scanning SERP pages, and writing well-crafted issue descriptions for better searchability is time you're not spending on the product. You can't ship the prose in your issue tracker.

</comment></comment></comment></comment><comment><USER10> This isn't really a new idea.

For anyone interested in 'systems thinking' and associated optimisations, check out the 'Implementing Lean' book:

[http://www.amazon.co.uk/Implementing-Lean-Software- Developme...](http://www.amazon.co.uk/Implementing-Lean-Software-Development- Addison-Wesley/dp/0321437381/ref=sr_1_1?ie=UTF8&qid=1341845698&sr=8-1)

Or The Goal for something slightly different:

[http://www.amazon.co.uk/The-Goal-Process-Ongoing- Improvement...](http://www.amazon.co.uk/The-Goal-Process-Ongoing- Improvement/dp/0566086654/ref=sr_1_1?s=books&ie=UTF8&qid=1341845732&sr=1-1)

I have to say, there's way more wisdom in the more mature 'lean' world than there is in the trendier 'agile'.

<comment><USER11> Using Joel's definition of inventory and then reading "The Goal" would be a useful thing to do.

IT and software shops often have no clue about what is actually stopping them from shipping product.

<comment><USER10> This is why I like lean and systems thinking.

There's so much subtle hidden cost in the system that nobody thinks to look at.

By stepping away from the process that you've fallen or evolved into and looking at the meta level, you can get some massive wins in terms of your productivity, quality etc for little effort.

</comment></comment></comment><comment><USER12> A couple of years ago we did "Bug Bankruptcy" at my old gig. We then instituted a policy: either a bug was worth fixing RIGHT NOW (or reasonably close to it, say after you finish working on your feature) or NEVER. Bugs that were re-reported by users we would move up our mental immediacy list. I like it because it didn't require a fancy software solution - just the group memory. It worked really, really well, and we continue to use it today.

<comment><USER13> You didn't actually lean out the process, you just pushed more work on to a different group of people.

Did people pay for this software? I can't imagine buying software that makes me find/submit bug reports and then on top of that re-submit them to actually get them fixed....

<comment><USER14> > I can't imagine buying software that makes me find/submit bug reports and > then on top of that re-submit them to actually get them fixed....

This is what pretty much all consumer infrastructure service providers rely on, though. One guy reports that his internet is out? Probably his fault. Ten people in the same area call in to complain in a one-hour period? Probably yours.

</comment></comment></comment><comment><USER15> I can't help but feel a bit irritated about this post of Joel's. It's rehashing some very old Agile ideas as if they were somehow fresh and new, all in support of yet another project management tool. (As if we need another one of those.)

Anyway, I'm glad he's helping to spread these ideas. I just wish Joel had been a bit more forthcoming about the rich history he's drawing from, and would give people the opportunity to read up on it in more detail.

(Relatedly, if you're interested in how these ideas apply to multi-team development, I did a talk at Philly ETE earlier this year about applying the Lean and Kanban to large-scale Agile development. Here's the video: <http://vimeo.com/43956744> )

</comment><comment><USER16> I wish Joel would go back to blogging about software dev in general rather than writing what I consider plugs for Trello.

</comment><comment><USER17> > A lot of the ideas on the backlog are bad ideas, and you merely wrote them > down to avoid hurting the feelings of the people who thought them up.

I love how candid he can be sometimes. In my experience, this is true of about 30% of the backlog.

<comment><USER18> In my experience it doesn't really become clear whether the ideas are good or bad until they've been written down. For this reason I prefer a two-stage backlog, where the first stage is for definition and the second stage is for the ideas from the first stage that you decide you're actually going to do, just not right now.

<comment><USER19> Yeah, I wouldn't get too hung up on the way Joel phrased it. Clearly ideas have to be considered to some reasonable degree, possibly run past a couple people from different departments, to see if there's anything there.

The trick is just 1) not spending _too_ much time on something after you realize it's anything less than solid 2) not moving them to the official "to do" list just to spare someone's feelings.

</comment></comment></comment><comment><USER3> Decreasing time between deployments is not guaranteed to always be a good thing unless you really do "work on deployments", which may not be best for your product.

Consider Firefox moving to six-week deployments and the negative impact it had. That could have been mitigated by a "work on deployment" that added value to a product.

Many enterprise software packages are painful to deploy. Having worked on these, I can tell you it is because hooking up a dozen systems is just complex. You could conceivably have a way to make that turnkey, but that "working on it" probably would not be good for your product as enterprise customers understand (and usually appreciate) the slower pace.

Somebody else said don't go cargo cult with this. I couldn't agree more, but certainly think about it, understand where it is wasting you money, and fix it.

<comment><USER20> Yes. This is a spot where Joel's analogy breaks down.

When a factory/bakery/whatever ships product, that's capital that's immediately converted to a liquid asset (cash). Unless your customers are paying per-feature as they are delivered (when does that ever happen? contracting?) software really doesn't work that way.

<comment><USER21> When your customers are paying for upgrades via support contract, and they don't get upgrades, they stop paying for the support contract. People have short memories, they need to see signs of activity. Delivering features they don't want gives them more hope that you will soon deliver the feature they do want, vs delivering no features at all.

</comment></comment></comment><comment><USER22> This concept reminds me of "Technical Debt" in that its a way of expressing what the software development world has found to be best practice in terms that an outsider/business-person would understand.

</comment><comment><USER23> He just reinvented Kanban: <http://en.wikipedia.org/wiki/Kanban_%28development%29>

</comment><comment><USER24> Reminds me of the story in Chuang Tzu about an old man who loses his memory. Various cures are tried to no avail. Eventually a learned doctor is brought in who after much effort succeeds in curing the man. In a flash, all his memories return. Immediately he proceeds to beat the doctor with a stick, saying "How dare you? I was doing great and now you've ruined everything!"

</comment><comment><USER25> Rather than emptying out the bug database, I prefer keeping two different "levels" of bug reports. There's the "current" bug database, which you try to keep small and which you clean regularly and work from. And there's the "deep backlog" which winds up being pretty much a collection of random junk. The "deep backlog" is rarely looked at (so it doesn't become a waste of time and attention), but you also don't throw it out wholesale, because it costs almost nothing to keep around. Occasionally you'll try to data-mine the deep backlog. You may also go through every year or two and do a mass cleanup; or you may allow a sort of "voting" process to identify items from the deep backlog that are worth considering for the "real" bug list.

</comment><comment><USER26> > That means on the average day you have 150 metric tons of wheat flour in > stock. At today's prices, you've tied up $73,000. Forever.

What's so bad about having that money tied up in inventory? Once it's in there, you can just forget about it, and it has no impact. If you reduce your inventory and "free up that money", you're just going to spend it on something else, and then be on an endless quest to forever reduce inventory, because the money you "free up" kind of looks like revenue, which you are obviously trying to increase. Continuing down this path has no future.

At some point you can't reduce inventory any more (lets even say you get it to zero with JIT), at which point your "revenue" will "fall" compared to last year/quarter and everything looks bad.

<comment><USER25> From an economic sense, the problem of the money tied up in inventory is precisely the interest on $73,000. (Interest rate you pay on loans if you have any loans, interest you'd get from a bank account if you don't have loans.) So around a dollar a day at today's interest rates. (It gets worse if you figure in the small probability of spoilage or damage that is uninsured.)

<comment><USER27> More concisely (or generally, or just nebulously), it represents an opportunity cost.

</comment></comment></comment><comment><USER28> Joel is saying what the lean-manufacturing inspired people have been saying for years. I think it is a mis-mapped metaphor.

When you diligently draw the parallels between manufacturing and software development you end up with the notion that the whole of your code base is inventory:

[http://michaelfeathers.typepad.com/michael_feathers_blog/201...](http://michaelfeathers.typepad.com/michael_feathers_blog/2011/05/the- carrying-cost-of-code-taking-lean-seriously.html)

</comment><comment><USER29> Good read. I think reducing deployment cycles into weeks for large/complex software could only work though if you have a decent set of automated tests.

<comment><USER30> This is valuable enough to justify writing the tests, isn't it?

<comment><USER31> No. Cutting your deployment time is equivalent to saving a one-off cost. A comprehensive set of automatic tests is a massive ongoing cost (it's by no means impossible for the tests to cost more than the product), forever. The latter vastly outweighs the former.

There are domains in which you need the tests anyway. If you're in one, you'll probably find your deployment cycle is also constrained by the nature of the domain. If it's not, and if the existence of the tests lets you deploy faster than you otherwise could have, well and good. But it certainly isn't worth investing in the tests just for faster deployment.

<comment><USER32> > Cutting your deployment time is equivalent to saving a one-off cost.

No, cutting deployment times produces ongoing savings in two respects:

1) Time is saved on deployment every release. That may be a small amount relative to the engineering that goes in ahead of releases, but it's definitely not a constant: it's proportional to the number of releases. When one considers not just major-version-every-six-month releases, but also maintenance releases, hotfixes, patches, etc., the time savings is increased even more.

2) As Joel discussed in the post, there are lost opportunity costs when a team develops a feature and does not immediately release it. Presumably, those features are intended to directly or indirectly increase sales/revenue: the sooner they are released, the sooner they can begin making the company money. This money is proportional to the number of features/improvements.

Investing the engineering effort required to achieve a shorter release cycle doesn't always make sense, but it definitely always produces value proportional to elapsed time.

</comment></comment></comment></comment><comment><USER33> Wherein Joel espouses an agile software development methodology and invokes the Toyota Production System.

And pictures of Taco the Husky are always appreciated :-)

</comment><comment><USER34> > (PS No, this is not "waterfall." No it isn't. Is not. Shut up.)

I love Joel's writing style.

</comment><comment><USER35> This looks about right for any kind of business, not just software development.

</comment><comment><USER36> Going off-topic here, but that was a cool dog. Looks like a huskie. :)

<comment><USER37> His name is Taco. He's a very gentle dog, although (as my fiancée discovered) one who moves like a bullet if you happen to be holding a bagel and lox and let your guard down.

<comment><USER36> Heh, thanks. Nice to know that Taco can be as fast as a bullet when the opportunity presents itself. :)</comment></comment></comment>


Show HN: Use Steve to turn your HTML mockups into apps in minutes - <AUTHOR> http://www.steveapp.com/

<comment><AUTHOR> Hi HN people!

I have been trying for a year to launch a product that would make it easier for people to build web and mobile applications without coding. This is my second attempt. Upload your HTML design files and Steve will transform them instantly into full featured applications. Please take a look at the demo and let me know what you think.

I built it in two weeks with AngularJS and a Node backend.

</comment><comment><USER2> Well, for starters, that music is absolutely ridiculous. I can't really see the point of having music at all in the screencast.

<comment><AUTHOR> Thanks! I will change it.</comment></comment>


Target, Schedule, and Preview Notifications in the Parse Push Console - <AUTHOR> http://blog.parse.com/2012/11/13/target-schedule-and-preview-notifications-in-the-parse-push-console/

<comment><USER2> This covers a lot of Urban Airship's value proposition. Are these two services finally coming into direct competition?

</comment><comment><USER3> Push all things all the time? <http://news.ycombinator.com/item?id=4774490></comment>


'Lean' Is for Mediocre Minds - <AUTHOR> https://allenleein.github.io/2019/12/06/lean-mediocre.html <comment><USER2> You're right. Lean will work (maybe) for all the boring, safe money-making schemes. May be a great way to start to learn how to run a business. But the fun is in the "bending"; creating a new type of business, maybe a new concept in technology entirely even if it's not "justified" by today's data. The idea is to irrationally "bend" success to what you've originated.

I know it sounds a little silly, but this is the best way I can describe my mentality when I had pursued any of my successes in life.

If not this way, than business is too boring for me :) Maybe I'll stick to programming and pick up painting.

<comment><USER3> I think you've completely missed the point of Lean. The novelty of your concepts is irrelevant; the point is to test your ideas as quickly and cheaply as possible

</comment></comment><comment><USER3> Lean is the scientific method applied to business: hypotheses are tested to make decisions. Nothing more</comment>


Show HN: Freaking cool JS game where you code your own bots and battle - <AUTHOR> http://fightcodegame.com/robots/create#docs

<comment><USER2> Love the design and great landing page explaining the concept, so why would you send me straight to ask me to auth with github without my even knowing what I'm getting into?

</comment><comment><USER3> totally uncool, sending people directly to github login page. i don't even know what to expect.</comment>


Apparently you can play snake on Youtube - <AUTHOR>

pause the video (must not have an ad) at 0:00 and hold the left arrow key for 2 seconds and then press the up arrow key and voila! Snake! I apologize if I was slow to come to this realization. <comment><USER2> Thats a fun easter egg. Any idea where a scoreboard might be?</comment>


Why the Quick Bar ("dickbar") is still so offensive - <AUTHOR> http://www.marco.org/3991237704 <comment><USER2> Marco nails it.

The whole value proposition of Twitter, historically, has been that you can make it _whatever you would like it to be_. Are you Captain Nerd? Load up that stream with the finest of curated nerds and be soaked in their wisdom, go! Are you nuts about celebrity culture? Sports? Food? Just want to keep up with your friends and colleagues? You're covered.

The Dickbar is a violation of that understanding that needlessly undermines Twitter's brand and utility among the fiercest of its loyalists. There are many better ways to monetize the experience here. AdWords-style keyword based stuff being the most obvious, and most likely to be virtuous. Pitch me awesome iDevice accessories and apps all day long – I bet I'd actually care about them. Design sites? I'll check it out! Magic kitchen tools? Where?! Awesome restaurants near me? I will eat there!

Sports? Celebrities? Hell. No.

This is crass and it's a fuck up, plain and simple. Five years from now we'll look back and one of two things will be on our minds:

"Wow, glad Twitter rethought that garbage and built something that truly worked for both users and advertisers. What a powerhouse they are."

"Twitter? Was that like Friendster or something? I think I remember it."

<comment><USER3> Targeted ads are so obvious that I don't understand why they haven't implemented it. Google did it successfully. Facebook did it successfully. In fact, if someone would have said to me a year ago "Twitter will totally ignore their massive pool of user specific data in favor of blanket ads!" I would have literally laughed in their face. "Twitter isn't that thick!" I'd say.

It reminds me of the time I tried to partner with a local print heavyweight over a local portal site w/ a super premo domain. His suggestion was to purchase and post AP content on it.

I just don't follow Twitter's strategy here.

<comment><USER2> It's truly just... insane. There's not a better word for it than that. My tweets are a wealth of data about things I care about. There are so many ways to sell truly useful ads against that – you have to be off your nut not to take this approach. Real-time ads that solve your problems without you doing anything more than gabbing away could make Google look like a two-bit lemonade stand.

"Fuck, I hate AT&T. Worst cell phone service ever."

"Join Verizon today! Get $100 credit when you switch from AT&T."

"... Go on."

edit: And assuming you use Twitter mostly for passive consumption, there's still useful to be derived from your stream. "Boy, this guy sure follows a lot of people from Portland, let's show him Moe's Bike shop ads."

<comment><USER3> How many dozens of Twitter NLP companies for tracking brands are there? Twitter should buy their favorite, and offer brand reinforcement and steal- away ads. Better already.

<comment><USER4> What's NLP? Google didn't help - unless it stands for 'Neuro-Linguistic Programming'...

<comment><USER5> Natural Language Processing, I think

<comment><USER6> thanks

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> It's not just the dickbar that's offensive - it's the fact that its release along with the announcement that Twitter is going to try to limit the development of other clients against their API that really makes it distasteful.

I understand that they have a need to monetize - I get it, but to do so in such a ham-handed way really bothers me.

<comment><USER8> Was just thinking about this, it would be great if they did do targeted advertising and did it through an API, so 3rd party clients could choose to include ads and both Twitter and the 3rd party takes a cut, or allow them to continue without advertising but ban other advertising meaning that they can only monetise by selling the app or including Twitter ads.

<comment><USER7> I think this is an AWESOME idea.

</comment></comment></comment><comment><USER9> _It's a news ticker limited to one-word items, lacking any context, broadcasting mostly topics that I don't understand, recognize, or care about. It's nonsensical. At worst, it can offend. At best, it will confuse._

That actually sums up Twitter as a whole. Try as I might, I've never been able to shift my perception of Twitter beyond that and into something that could ever be useful to me in any way.

Look at the bottom 80% of those screenshots to see what the "real" twitter gives you. I can only assume that the author has subscribed to that content, and it's every bit as useless, to pretty much anybody.

<comment><USER10> "I think Twitter's a good thing. Why say a lot to a few people when you can say virtually nothing to everyone"

\--Jerry Seinfeld

<comment><USER11> The best analogy I've heard of Twitter is it's like I were to stand on my balcony and shout at the crowd below.

</comment></comment></comment><comment> DanI-S I'd be interested to hear what 'normal', non-power users of Twitter think. The 'mouth-breathing buffoons' that Jeff Rock so denigrates (and evidently make up most of Twitter's users) may actually _like_ this UI feature.

Viewing the world through nerd-tinted spectacles makes many things seem horrible that are perfectly OK to a regular person.

<comment><USER12> It shouldn't matter.

In 2011, people interested in NCAA basketball should see sports stuff. People interested in Ruby on Rails or Amazon EC2 should see IT stuff. It should be pretty easy to spot people's interests on Twitter.

Amazon.com doesn't recommend women's clothing to me. Netflix doesn't show me Spanish language movies.

<comment><USER13> This is an interesting idea that I haven't seen before. Why shouldn't Twitter target trends at me? They know my tweets, and tweets of the people I follow. They could target trends, and ads for that matter, that I'd actually like to see.

<comment><USER14> > Why shouldn't Twitter target trends at me?

Maybe they can't. They sure lack some core competence by not being able to block obvious spam accounts (Newly created accounts that: posts trend spam, do mass following and mass @mention, etc).

<comment><USER15> I'd love to hear someone from Twitter explain why the service seems to lack even basic automated spam detection. The only mechanism that seems to exist is the "report as spam", which takes so long to suspend an account I wouldn't be surprised if the process was manual.

</comment></comment></comment></comment></comment><comment><USER12> The funny thing is, clients like Twitterrific and Tweetie pre-Twitter takeover managed to figure out how to monetize the client years ago.

The Fusion Ads that were featured on Twitter in particular were excellent -- I actually found some the ads interesting enough to click on.

</comment><comment><USER16> Am I mean for just not caring what's currently trending on Twitter? Feels like a similar problem to showing ads on blogs. I'm there for the content and the ad has to be exceptionally good in order to get any of my attention.

<comment><USER17> Because I am an engineer and I battle distractions all day, I have always thought of hashtags as Twitter's dumbest feature. Back when Twitter was new it took me weeks to understand just why people were complaining about spammers. How could you be spammed on Twitter? I asked myself. Shouldn't you just unfollow the spammer and get on with your life?

But since then I have had the occasion to witness marketers using Twitter. And I have learned that, to a marketer, hashtags are pure heroin. You get to eavesdrop on strangers discussing products. You can count references to your product, and to your competitors' products. So what if this activity bears the same relationship to actually getting out of the building that playing Rock Band does to a real blues jam? It's a rush, and it comes in optimal tiny doses like Snackwell cookies, and it almost feels like productive work. From what I can tell a majority of the marketers in the world have Tweetdeck open all the time and wince reflexively every time anybody on Twitter says anything bad about their pet trademarks. To ask them to do otherwise is like asking a novelist to stop compulsively reloading their Amazon sales rank over and over.

<comment><USER18> Without hashtags, you can still do most of this with regular ol' keyword searches. So I think search is your real enemy here, not hashtags.

<comment><USER19> Yeah, folks at my company follow discussions about our products on Twitter and it doesn't matter whether the person uses a hashtag or not. What you need is a distinct product name though, to only discover relevant tweets.

<comment><USER8> Hashtags make it easier, sometimes people don't provide enough context or use the same words you would for a product or service, if people start using a common hashtag it makes it a lot easier.

An example of this that I used a bit in my thesis (admittedly not product based) was the #ausvotes hashtag for the Australian elections. There were plenty of Tweets that would have been very hard to identify as related to the election without that hashtag because they were mostly thoughts or opinions without context.

</comment></comment></comment></comment></comment><comment><USER20> I agree with Marco Arment and Jeff Rock in that it is perfectly understandable that Twitter wants to monetize their business if they wish to do so, but based on their recent decisions it seems that they are taking a path that will damage their business along the way. Also, I have never understood the value of trending topics. It is just one of the many metrics inherent to how Twitter works, but it is far from the most useful metric since Twitter is so full of spam and people that have nothing useful to say (which is their good right of course).

Anyway, all this does make me curious to see how Twitter is going to change in the next few months and I hope for the best - for them and for the users.

</comment><comment><USER21> "Am I supposed to tweet about it? If so, why doesn't the interface encourage that? Even if I hit the (effectively invisible) New Tweet button from this screen, my tweet isn't prepopulated with "#michigan", so whatever I say in response won't be included here."

The new tweet button is the same size and in the same place as in the rest of the application. Trying the button and it does auto fill the trending hash tag.

The rest of the article hits the point, but there is no need for these inaccuracies.

<comment><USER10> And imagine if the interface did encourage Marco to tweet about it. Then what would he say? "Why should I tweet about this crap? I'm double offended!!"

</comment></comment><comment><USER22> The whole thing is mind-blowing.

Shortly, Twitter should be more profitable than Google.

How Google makes money? More or less, they sell queries. They do not know the right price, so they let the market to figure it out. It works extremely well but they are able to flood someone with ads only about 10-20 times a day.

Twitter, on the other hand, is able to flood with ads all the time. Actually, they are able to _push_ ads, instead of having to wait for a query. Twitter is able to auction with more "vectors", such as location, whole feed, followers etc. They do not have to do any information retrieval over this data, it is already provided with the structure.

Twitter does not have any privacy issues. It is already assumed that nearly everything you post on Twitter is public, so no one is going to screw them for using this. The data posted on Twitter is not sensitive, unlike Facebook.

Also, there is a huge value about the way they receive the data. They have a significant edge over the old web, as they get a lot of things before the whole world. What is even better, they do not have to _pull_ this data, people _push_ it to Twitter. They have data faster and they do not have costs related to crawling the web.

So, if for some reason they do not want flood people with ads, they are also able to auction immediate notifications about queries, the whole stream of tweets, some parts of it. They are able to set the minimum price of each auction so they offset their costs. Everyone focuses on Twitter as a marketing channel but there are many, very profitable, industries that live by the speed, die by the speed.

And do not get me started with the control they have over links posted in Tweets...

EDIT: typos

</comment><comment><USER10> Look at those screenshots. The ad is nowhere near offensive. At most, it's slightly distracting.

The self-righteous sense of entitlement of people using free stuff on the internet never ceases to amaze me.

<comment><USER23> I don't think you read the article.

<comment><USER10> I did. What's your point?

<comment><USER23> Ok, then, where is the entitlement you are sensing? I couldn't find any.

<comment><USER10> He's raising a stink about a company's (poor) attempt at making money by causing its users the slightest inconvenience. That ad uses what, less than 10% of the screen space? Now, you can criticise how bad or ineffective the ads are. But, no, the dude is offended! He feels entitled to get even more from Twitter than what he's paying for, which is $0.

It's like if I got offended for Instapaper charging money for a premium subscription. No, I'm just grateful Marco's built an amazingly useful tool and is letting me use it for free. I'm not entitled to more than that.

<comment><USER24> He didn't raise a stink about Twitter trying to monetize, he raised a stink about them making a well-designed app ugly and less relevant to its users.

</comment></comment></comment></comment></comment></comment><comment><USER25> The "dickbar" is offensive because it needs to be. Costello knows that we'll hate whatever sneaky scheme to redirect our attention so he's probably giving us something to complain about first so that when they release the intended concept, it'll feel less offensive. Feeding ads into the stream would cause an uproar. Adding a banner will generate banner blindness. What better than to overlap the add with something we'd find useful but still sideband?

</comment><comment><USER26> What I find interesting about this analysis is the fact that Twitter _could_ presumably "fix" the dickbar by finding a way to make it 1)useful and 2) targeted to the user.

After years of Twitter claiming that they were going to find a way to monetize without resorting to irritating advertisements (and after billions of tweets) they presumably have the knowledge and ability to do this. The question really is, "do they want to"?

</comment><comment><USER27> I deleted the twitter app from my phone as soon as I realized the dickbar was something I couldn't opt out of. Now I use hootsuite. Deceit UI, multiple accounts, and I can post across accounts and(something twitter doesn't do) schedule tweets to post at a later time. Twitter had made a serious miscalculation with the dickbar. They've reminded users there are other clients out there they can use. And if twitter decides to shut off API access for those clients, a LARGE percentage of people will simply stop using the service. I will.

<comment><USER27> And as an aside, according to [http://www.techspot.com/news/40459-twitter- passes-myspace-in...](http://www.techspot.com/news/40459-twitter-passes- myspace-in-traffic-adds-12tb-of-data-per-day.html) twitter is storing 12TB of data per DAY! Anyone who cannot monetize that volume of data without annoying ads and dickbars doesn't belong in business.

<comment><USER28> Not that I disagree that they shouldn't be doing a better job with the dickbar thing, but analyzing 12TB of data per day and cross referencing it with petabytes of earlier data does actually seem very challenging. I can't think of too many companies currently doing this, so it's not like you can just google "how to data mine petabytes" to get a step by step tutorial.

<comment><USER3> You are very right. But, why not start simple and just lump people in broad categories based on follows.

Jessica follows a lot of celebrities. Bryan follows lots of tech icons. Billy follows lots of comedians. Etc. Etc.

Even that isn't _easy_ but it is hundreds of times more likely to work than blanket ads and last I heard they have millions in VC money. Spend it on talent specifically for this.

<comment><USER28> It's definitely something they should be focusing on.

</comment></comment></comment></comment></comment><comment><USER29> I think that many of the same people offended by the Quick Bar would be the same people that are willing to (and often do) pay for a client. What reasons could Twitter have for being averse to a freemium model in this area of their business? $1/month to go advertising free? I'd pay it. Since they introduced it, I've always found the trending topics area of Twitter to be the worst thing about it. I, like so many others, object to having it stuck in my face every time I open their app.

<comment><USER30> That would be a huge mistake. Doing that kills the value of their product to advertisers. You've just taken away the customers most desirable to advertisers (those willing to spend money). Ad pricing falls off the cliff.

</comment></comment><comment><USER31> I'm no iPhone user so I'm curious as to why this is such an issue? As far as I can tell it's just ads in a free app? (unless, it's not free then it makes more sense)

<comment><USER15> Many of us paid for $3 Tweetie (and $3 for Tweetie 2) because it was by far the best Twitter client for iOS. It's free now, but we paid for it.

The statements from Twitter that people shouldn't build new Twitter clients coming out in the same week made the backlash worse, too.

</comment></comment><comment><USER32> Maybe the bar should only appear when one conducts a search - so it could have some relevance to what is being searched - rather than right on the main screen.

</comment><comment><USER33> I think part of the thing missing here with regard to the "dickbar" is "context". The short time I used the official Twitter client before changing to another one was that the "dickbar" had no relation to what I was actually interested in.

The UI was intrusive, yes, but what was presented was more offensive. Fix/soften the UI impact and make the "trending" topic more appropriate and things would be less offensive.

</comment><comment><USER34> Not just that, with the new update every time you launch the iPhone app it asks you "Twitter would like to use your current location, allow, don't allow"

No means no

<comment><USER35> That's interesting. The alert should only be presented to you twice - if you respond No to both cases, it should simply disable location services for the app.

Mind you, I did that manually - at least once I discovered it leaves them enabled the whole time the app's running, which means a significant battery hit on the GPS.

</comment></comment><comment><USER36> Marco totally nailed it. At this point I'd rather something adsense-like that can push ads I could be interested in (possibly with the quality of the Fusion or Deck ads).

</comment><comment><USER37> I've yet to find any use for trending topics generally. I prefer Favstar's quality curation based on most "faved" tweets by topic.

</comment><comment><USER38> Let me rephrase from earlier -- is Twitter technology patented?

<comment><USER39> Why?

To reiterate, yes you could build a clone, but the odds of duplicating Twitter's success is almost nil at this point.

Or are you asking if they're legally capable of forbidding people from creating other clients?

<comment><USER40> The tech (multicast messages) isn't patented, and there's no legal prohibition on creating clients. The only client concern is that clients use OAuth, and can be disabled by Twitter staff as necessary. A disabled client is probably legally barred from returning to the service too.

</comment></comment></comment><comment><USER41> Meh...get over yourself Marco. Just because you aren't interested in these topics does not mean others are not. That's why they are trending in the first place.

<comment><USER42> He made a somewhat interesting point around this -- that even if you do hapen to be interested in a trending topic and select it, a bunch of mostly unrelated spamish tweets will be there to greet you when you select the topic.

<comment><USER41> That happens on search.twitter.com also, so it's not limited to the trending topic bar.

</comment></comment></comment><comment><USER38> Is the sms -> internet/ server -> sms pathway tied up in business patents by Twitter? I am sure I am (sort of) underestimating, but Twitter seems like a weekend project for a couple of decent hackers; if they piss enough people off is there any reason to stick with them except for (VERY non-trivial) first past the post market share?

<comment><USER39> Ooh, another "it's just a weekend project!" comment.

Next step: convince everyone to use your weekend project, instead of Twitter. Allowing people to import all of their tweets and friends would be helpful, so be sure to implement that.

Next next step: Handle all of Twitter's traffic. Consistently, and you not only have to do it _better_ than they did in the beginning, but better than they do it _now_.

<comment><USER43> Also create mobile clients for everybody to use. And don't forget about an API.

<comment><USER44> I don't think this will be an issue if he manages to maintain the same API as Twitter.

<comment><USER15> How many Twitter clients support third-party API endpoints?

<comment><USER45> Ironically, I believe Tweetie 2 used to, before Twitter bought it. It allowed a lot of advanced customization.

<comment><USER15> It actually still does, for now. I wonder if the #dickbar shows up on third- party timelines...</comment></comment></comment></comment></comment></comment></comment>


A Company Prospers by Saving Poor People's Lives - <AUTHOR> http://www.nytimes.com/2009/02/03/health/research/03prof.html?ref=health&pagewanted=all <comment><USER2> Bright young businessman starts up, achieves success, starts expanding, coup happens and he is forced to leave country.

There are a lot of reasons you could point to why Africa is still Africa, but the depressing regularity of "and then there was a war" has to go near the top. They will never be rich without capital and they will never have capital until it can doesnt regularly get stolen, burnt, or shot.

<comment><USER3> They have wars because their borders were drawn by colonial exploiters with no regard for the ethnic groups of the people living in the land. Africa should have twice or three times as many countries than it has now.

Also, the United States and other wealthy nations destroyed some African democracies in the 60s and set up puppet dictators. For a horrific example, learn about the U.S. backing of Congo's dictator and the resulting wars in which 5.4 million people were murdered and millions of women raped. God Bless America.

The U.S. continues with the same foreign policy by supporting a warlords in Somalia.

<comment><USER4> _They have wars because their borders were drawn by colonial exploiters with no regard for the ethnic groups of the people living in the land. Africa should have twice or three times as many countries than it has now._

There weren't many nation-states before that - the keyword here is "nation" which is quite different in meaning from the word "tribe". When you have a ethnic map looking like kaleidoscope nation states aren't very sensible. The few stable African countries - RSA, Senegal, Ghana have more than the average number of ethnic groups even for Africa.

 _Also, the United States and other wealthy nations destroyed some African democracies in the 60s and set up puppet dictators._

I'm sorry but while true, this is not the whole truth. The US wanted to stop Communism in Africa and it did back some "right-wing" butchers and dictators against the left-wing ones. The record shows that communist dictators are almost always much, much worse and even when they are in power they mismanage the countries into oblivion. Yes, I agree that there had to be a better way, but you cannot simply claim that it was done from greed and wickedness. That just makes you sound the Pravda newspaper: <http://www.gazeta- pravda.ru/pravda/logotip.GIF>

The USSR, its Warsaw Pact allies and other communist countries like China and Yugoslavia, are much more responsible for Africa's troubles than the US. Communist provided "freedom fighters" with arms and corrupted and manipulated governments. Money from arm sales were crucial for some of these countries, because they badly needed foreign currency. Also "world revolution" was a stated goal and you had to have a global war (read some Marx, Trotsky and Lenin if you don't believe me). Che Guevara and Mao thought that conquering poor countries was a good way to win globally and their post-Stalinist communist plot was really the only paradigm commies could realistically follow after the invention of nuclear weapons (you obviously cannot launch a WWIII to conquer Europe and the US).

The Communists actually won in most of Africa around 1991, with the most notable exception of Zaire, which was ruled by US-backed kleptocrat who then became "non-aligned". They obviously wiped out the anti-communist forces, but it wasn't all pretty. The new rulers didn't know how to rule the countries and even the peace was short-lived because the poverty which they only made worse made it easier to create yet another generation of warlords.

Africa had the bad luck of becoming the battleground of the Cold war.

The USSR did in fact win the Cold war in Africa - most of the regimes were pro-Soviet, but that brought little value to the Communist block. Che Guevara was wrong - the communist system of world revolution wasn't sustainable and no external success could remedy the many flaws and internal problems the USSR had.

 _For a horrific example, learn about the U.S. backing of Congo's dictator and the resulting wars in which 5.4 million people were murdered and millions of women raped. God Bless America._

Are you sure the U.S. had chosen a side in the Second Congo War? After the Cold war, Africa stopped being so important. Most of the leaders on _both_ were pro-Soviet during the Cold war. I don't see how

America is currently loved in most of Sub-Saharan Africa. Clinton and Bush had a friendly relationship to Africa (the latter greatly increased the volume of the aid, making the continent one of the few places in which he was popular) and Americans just elected a president who has huge ties to Africa.

</comment></comment></comment><comment><USER5> "To promote the straws, Torben has let television crews film him drinking out of Copenhagen's canals and even a toilet."

Now that's eating your own dogfood.

<comment><USER6> ...after the dogfood has already been eaten once.

</comment></comment><comment><USER7> After introducing a bribe:

 _"In one week, the percentage of adults in the district who had taken a test went to over 80 percent from less than 20 percent"_

Think of all the expensive public service announcements we see in the U.S. (AdCouncil etc.). How many more objectives would be met if this more cost- effective strategy were adopted instead?

In this case the bribe contents looks pretty useful. But even with junk, people will waste silly amounts of time in line if it's free.

</comment><comment><USER8> No login required:

[http://www.nytimes.com/2009/02/03/health/research/03prof.htm...](http://www.nytimes.com/2009/02/03/health/research/03prof.html)

<comment><USER9> Login required!

<comment><USER8> Ah. I went to Google with this search:

[http://www.google.co.uk/search?hl=en&q=Vestergaard- Frand...](http://www.google.co.uk/search?hl=en&q=Vestergaard- Frandsen%E2%80%99s+products+are+used+in+refugee+camps+and+disaster+areas+all+over+the+third+world+and+are+not+only+lifesaving%2C+but+even+beautiful.&btnG=Google+Search&meta=)

The top link gives my the same URL, but now I don't need a login. I wonder if NYT checks the referrer, and since mine was Google it let me read the entire article.

Apologies for any inconvenience or confusion. If you click the Google search link above and follow the reference it may well work for you. In future I'll extract the link and open it in a clean browser just to be sure.

Thank you for bringing this to my attention.

<comment><USER10> A Google referrer doesn't do the trick. It's a cookie thing. <http://news.ycombinator.com/item?id=460294>

<comment><USER8> Thanks.</comment></comment></comment></comment></comment>


Koding.com is public - social development in the cloud  - <AUTHOR> http://www.koding.com This looks pretty well designed. Haven't jumped into the guts yet, but seems well laid out. <comment><AUTHOR> Think they could probably use a better landing page then showing the activity stream. Here's a two minute video that shows it off a little better.

[http://www.youtube.com/watch?v=zCHKLvpIXUA](http://www.youtube.com/watch?v=zCHKLvpIXUA)</comment>


Ask HN: Do you have a custom-payment-system horror story? - <AUTHOR> You always hear that it's usually a bad idea to write a custom payment system. Let's share why.

    - Maybe you charged your users multiple times?
    - Or charged somebody way too much?
 Let's hear it! <comment><USER2> Man, I've got some stories. A few years back, circa 2014 I installed & set up PCAmerica CRE for a business. We used Ingenico ISC250 pinpads with direct integration which turned out to be a very poor decision! For a span of a month, those damn pinpads randomly double charged debit & EBT customers (which we reversed in bulk afterward), and the building got tagged saying "You stole $20 off my EBT Card". Ended up swapping in FD35 pinpads, but the damage was done.

Another time, I was down in Cali visiting family. Stopped in at the 7-Eleven caddy corner to where I was staying, and accidentally pulled a shim out of the Ingenico ISC350 that was sitting on the counter. What a joy! From what I hear, that 7-Eleven still has issues with that type of stuff, so much so that my family started paying in cash.

Also met some guys who were working on this pinpad integration for Pax, sounded like the API was designed back in the serial days (with the limitations that entails) and they were trying to make the best of it. Items onscreen worked, but you couldn't display the live total, Pax had designed their own coordinate pair protocol instead of sending a SVG of the customer's signature, etc. IIRC this is the library they published: [https://github.com/AccelerateNetworks/PHPax](https://github.com/AccelerateNetworks/PHPax)</comment>


UW team wins AI prize for optimization approach - <AUTHOR> http://phys.org/news/2015-08-protein-self-driving-cars-uw-team.html <comment><USER2> Minor nitpick, it took me way too long to figure out which UW this is.

<comment><USER3> It's University of Washington.

</comment></comment><comment><USER4> This looks like a big deal to me. Why such a small splash?</comment>


What programming languages do people hate most? - <AUTHOR> http://www.quora.com/What-programming-language-do-people-hate-the-most <comment><USER2> Hatred of languages is pretty silly. I'd only go so far as to say I have _frustrations_ with particular languages:

\- Java: too verbose, no convenient way of passing functions around (anonymous clases are too verbose and clunky), lacked of unsigned types (apart from char) is sometimes irritating, mutable Date object is REALLY annoying. CHECKED EXCEPTIONS.

\- Python: sometimes the acrobatics you have to do to get everything indented correctly (on a statement that covers multiple lines) is a bit irritating. I actually get a bit irritated by the "superfluous" colons. Module/variable name collision. The amount of times you have to write "self" (compared to, say, Java where 'this' is implied nearly all the time). Lack of a range/xrange that includes the final element.

\- Javascript: it's important to separate Javascript the language and the DOMs in which it most often inhabits. Everyone has frustrations with the DOM, different behaviour and so on but the language is actually quite nice. My biggest frustration around JS is that debugging is probably the hardest of any interpreted language I use. Crude scoping (eg "var s = 'foo'" in an inner loop will have that defined outside of that).

\- C: I love the simplicity and elegance of C but the lack of try-finally semantics (not that I'm advocating exceptions in general). The mess you can get into of who is responsible for freeing memory (caller or callee). Macro acrobatics (you've never seen so many parentheses in your life).

\- PHP: inconsistent naming and parameter ordering. This is often cited but I think it tends to be overblown. You get used to it so at some point it simply offends your aesthetic sensibilities, which says more about the observer than the observed. Deep magic frameworks (I pretty much hate them all). People who try and turn what's actually a quite convenient templating language into Java/MVC. No cross-platform 64 bit int type. Really crude lambda semantics.

It's quite popular amongst programming language hipster-wannabes to hate on Java these days. The language I get closest to hating is... C++.

I've never in my life seen such a horrifically convoluted mess and if you look at C++0x (which is really C++1x now) it only gets worse. You see that every shop that uses it uses a (typically different) subset of the language because no one in their right mind would having coding standards allowing it all. Those slices can be pretty narrow too.

<comment><USER3> > It's quite popular amongst programming language hipster-wannabes to hate on > Java these days.

I'd say the hatred-du-jour has switched from Java to PHP in recent years. Java still gets a lot of heat though.

</comment></comment><comment><USER4> Hatred is predicated upon use, or

 _There are only two kinds of languages: the ones people complain about and the ones nobody uses._ <http://en.wikiquote.org/wiki/Bjarne_Stroustrup>

<comment><USER5> > Hatred is predicated upon use

That's not true -- plenty of people hate Lisp who've never used it.

<comment><USER6> Never met someone that really knows Perl well that thinks the syntax is a big problem or it's a "write only" language. It's all people who were scared off before they saw the light. Almost always the same with Lisp, vim/emacs, etc. Anything that's too foreign looking causes fear and then hatred for the fear it caused.

</comment></comment></comment><comment><USER7> I don't think it's helpful to hate on languages; it's healthier to discuss _frustrations_ that have got in the way of doing what you want, and how language feature x discovered in language y is a wonderful solution to the problem at hand :-)

</comment><comment><USER8> Interestingly, I started hating PHP when first doing a personnal project in college. It was a complete unmaintainable mess. Later, when I used it professionally, I learned to do things right (using frameworks and the like) and started liking the language. I think hating a language is more about what you had to do with it, and how you did it.

On another note, I'm surprised not to see Javascript at all in the list. It used to be seen as one of the worst languages to work with. It's weird how fast these things can change.

<comment><USER9> I think JS was mostly hated because of the available implementations at that time and the differences between them.

</comment></comment><comment><USER10> This programming language hate is pointless. If this was answered 5 years back Javascript could have been at the top. Now it is the most beautiful and flexible one. My jerk reaction at this moment is Perl and PHP b/c of widespread quotes against these one. But still i think they are very much worth learning.

</comment><comment><USER11> Hating on languages is immature and ultimately pointless. Every generation of coders seems to need at least one language to bash and project their frustrations on. It used to be VB Script, now it's PHP.

Enjoy your bashing while it lasts. Tomorrow your "{elegant,robust}" language will be the one that's obsolete.

<comment><USER12> I hate Java. ~10 years ago I thought Java was an improvement on C++ at the cost of efficiency. Unfortunately so did the "enterprise" market which infected the stack and the ecosystem that evolves around it.

Anyway, I don't think it's pointless to hate a language. By turning down projects that use Java my work life has improved significantly.

Edit: I still use Java when writing tiny multi threaded projects that communicate over TCP/IP. But, IMO everything has it's nitch.

<comment><USER13> > I still use Java when writing tiny multi threaded projects that communicate > over TCP/IP

Sounds like a good reason to learn Erlang.

</comment></comment></comment><comment><USER14> I've never hated a programming language until I met LabVIEW. In all honesty, the reply about LabVIEW is absolutely correct. Even PHP doesn't compare to the monstrosity that is LabVIEW. The FIRST robotics competition promotes using C++ or LabVIEW to create your robot code. And I have to say, programming by connecting squares together didn't feel like programming at all. It felt like I was being infantilized. The "source code" just becomes a whole mess of boxes and lines overlapping each other and just drives you nuts trying to understand how the program works.

Even though higher level programming languages are supposed to abstract the difficult parts away from you, LabVIEW abstracts you to the point that it's a whole new level of complexity, which completely defeats the purpose of it being abstract.

</comment><comment><USER15> This is a too subjective question. I thought quora was about fact, building a database of knowledge whre each answer is as clear and complete as possible? Hate is about passion, not aboug fact. But to answer the question, i don't hate any programming language: i know a lot of them and depending of the needs i choose the one that fit the most.

</comment><comment><USER16> The single language I hate most is Javascript. I loathe the wieird prototype- based inheritance (need a framework for something simple as subclassing), lack of modularity ("include" everything? really?), and strange handling of "this" (no bound methods). And then I don't even start about the difference between browser implementations.

So silly, for even the simplest things you need a framework. Code written for one framework is not compatible with code written for another framework, so you find this nice widget or library but need to port it first before it fits into your application.

I only use Javascript because there's no other choice for client-side browser development (yes, there's things like GWT, they're not that much adopted so you lose most of the advantages of code already out there, and they compile to JS anyway).

PHP comes second. I'm mostly frustrated with PHP for the way most people use it (mixing up presentation and logic in the web root), and the insecure-by- defaultness, not for the language itself.

</comment><comment><USER17> I think it's important to separate complaints about languages themselves and those about the _spirit_ of the language and how it came into being. For example, I think people who hate on Java and Perl would probably agree that their designers had noble goals and clear thinking but, being human, produced flawed implementations.

On the other hand, there are deeper things to legitimately hate in the _spirit_ of languages and how they came to be. C++'s 'everything but the kitchen sink' feature set reveals a lack of the essential job of _curation_ in its design. I think it's fair (and not silly) to 'hate' this flaw, since it means you've observed and learned from that mistake. PHP's evolution has stemmed from the "screw it, just hack it out" mentality, with less thought to long term consequences of design decisions and inconsistencies. This attitude bleeds into the work built with it. I think it's fair to 'hate' these things, since they are important cautionary tales for people who set out to build something new for the world.

</comment><comment><USER18> ATLAS [http://en.wikipedia.org/wiki/Abbreviated_Test_Language_for_A...](http://en.wikipedia.org/wiki/Abbreviated_Test_Language_for_All_Systems)

"The ATLAS language was initially developed by an international committee made up of representatives from the airline industries, military services, avionics manufacturers, and Automatic Test Equipment manufacturers. The goal of the committee was to design a standard English-like language that could be easily understood and used by both avionics and test equipment engineers."

The result was the goatse of computer languages.

</comment><comment><USER19> It's weird, I only meet intense hostility/hatred/dislike for PHP on websites like this. Is it some sort of geeky way of appearing cool, or do people genuinely dislike it?

I can't say I dislike any language that I have used.

<comment><USER20> There are things I dislike about PHP as such; it picked up Perl's sigils, but inconsistently; is $x a scalar, a list, or or a dictionary? Its support for first class functions just isn't there (in 5 anyway), and using "map' is a pain. None of these are anything like showstoppers.

What sets my teeth on edge is some code I have inherited, which takes all the possibilities available to the new & undisciplined programmer, and runs with them. 2000-line scripts with mixed HTML and code, global variables used indiscriminately, dead code here and there. None of this is PHP's fault, but reflexively and unfairly I associate it with PHP as a language. I suspect that this is where most of the dislike of PHP comes from.

<comment><USER3> Actually, since 5.3 PHP has had anonymous functions. The implementation is a bit of a kludge, but they're there.

</comment></comment></comment><comment><USER21> I have distastes towards some languages I've had limited exposure to. Pretty much, these are languages I had to use, but not languages I had to get good at using. Among these would be PHP, VB, and maybe Java (though I actually liked it before I started using C#).

Then, there is JavaScript, which I cannot avoid using despite having concerns with it. I would not say I "hate" it though, it's more of a "love and hate" relationship that formed over time here. I guess I look at it as being in a large city: if you know where to go it can be a wonderful time, if you don't you'll be shot in the face.

Among the things that bother me the most are function only scope, specifically when it mixes with declaration hoisting and implied globals. You can really end up writing some deceitful, innocent looking code that just does not do anything you'd expect it to. It's somewhat simple to avoid any problems that might come up if you're aware of them, but it's made me extra touchy; I get uneasy feelings when I see a variable declaration that is anywhere except the top of the function it is declared in. At the same time, having a large distance between the declaration of the variable and its use has been somewhat problematic for me: if I change the name of the variable, I must also remember to scroll up to change where it was declared, otherwise I just added a new global property. This bites.

The other significant issue I have is inheritance. I wouldn't mind if it actually resembled normal prototype based inheritance, but it just doesn't. It's too mixed up with the classical approach, making the end result neither simple nor powerful. It's easy to see that this problem in the language since there are so many different patterns of creating and extending objects as a result. Almost every framework/lib uses a different approach and tries to abstract it so the end user doesn't have to be aware of it. Of course, that only gets you so far before you end up having to look at how the libs you're using implemented it, and that sort of defeats the reason for the abstraction in my opinion. Something as fundamental as this shouldn't be so problematic, but it is.

Strangely, when I'm looking at EcmaScript 5 and Harmony, and see the changes that might try and fix these things, I kind of feel sad because it just wont be the same JavaScript I got used to fighting with.

</comment><comment><USER22> I hate using a screw driver with nails and I hate using a hammer with screws. It seems to me that with any tool there is a specific problem or set of problems it is intended to solve. There is also a (likely) larger set of problems that are very difficult to solve using the tool. Why are we blaming the tools for their users' mistakes. If a carpenter uses tools insufficiently suited for his project, do we blame the tools or the carpenter?

</comment><comment><USER23> I don't really hate any language, but i have a few dislikes:

1) PHP - for inconsistency and security bugs (did you know, that you can inject into mongodb with PHP? :)

2) Perl - for write only style.

3) C/C++ - for manual memory management and subtle bugs, which manifest itself long after actual bug happens (once i was searching for a rare-triggered bug in the C server for several months).

4) Java - for over-engineered APIs and verbosity.

<comment><USER24> re: 1), I assume you mean by passing an array with $operators into code that gets executed naively? If so, that's not just a Ruby problem; it's possible in any language, especially if you're working with a framework that automatically parses query variables and you don't typecheck/typecast before passing user data to your database.

<comment><USER23> Nope, PHP silently converts URL parameters into arrays (and if you don't expect this, than you can get a nasty NOSQL inject)

<http://www.php.net/manual/en/mongo.security.php>

<comment><USER24> Yeah, that's a problem in lots of languages/frameworks. Rack automatically parses URL parameters like that, too. The solution is to cast your parameters to a string before using them.

</comment></comment></comment></comment><comment><USER25> Vb gets a lot of hate.

I'm going to go with Java. So verbose, so stale. The worst part though is that Java developers don't seem to realize this.

<comment><USER26> _The worst part though is that Java developers don't seem to realize this._

As a counter, I humbly submit: Scala, Clojure, Groovy, JRuby, and JPython. A collection of languages that attempt to fix Java's (legion) problems, while allowing us (clueless?) Java developers to remain on a platform that continues to put food on the table.

IMHO, Java developers are the MOST keenly aware of the shortcomings.

BTW, VB does get a lot of hate, but it has a fabulous niche - MS Office COM interop. Down that road lies madness, and a ton of consulting dollars.

</comment></comment><comment><USER27> If PHP sucks so badly, why is it so popular? :)

You can call PHP anything you want but, the fact remains: it's easy to learn, and it gets the job done. It's not meant to be OOP like, if you want to go crazy with OOP, then go with a strongly typed language.

</comment><comment><USER28> Stretching the definition of programming language a little, but CSS is pretty awful.

</comment><comment><USER29> My favorite job interview question. There is no right answer, but any answer says so much about the programmer being interviewed that you might as well not bother with the rest of the interview.

</comment><comment><USER30> Why Quora is spamming HN and Techcrunch !!

<comment><USER31> Is that a Questment! (Something that starts as a question and ends as a statement)

George W was a master of it: he would start to say something controversial, then raise the intonation at the end.</comment></comment>