High-Performance Web Applications in Haskell - <AUTHOR> http://qconlondon.com/dl/qcon-london-2011/slides/GregoryCollins_HighPerformanceWebApplicationsInHaskell.pdf <comment><USER2> Can attest to Haskell and Snap being excellent for small web services where you need a boost - especially when concurrency is involved.

Wrote two small services for <http://www.webpop.com> in Haskell, both based on Snap. One for dynamically resizing images on the fly and one for handling uploads of large files and streaming them straight to Cloudfiles.

In both cases I started by trying node.js (both cases deals with either fetching or sending files from Cloudfiles so IO operations is what takes time) since the problems seemed very suited for node's eventloop model. In both cases node.js really disappointed.

Ended up giving Snap a try and got really surprised at just how well it worked. Performance is amazing, it's not much more code than the node.js version and theres no endless nesting of callbacks. It handles high levels of concurrency incredibly well and both services ended up using around 8MB of memory each - even under load...

Main problem is the lack of libraries that you tend to take for granted in more webby languages, and obviously the learning curve is pretty steep (but also very rewarding).

</comment><comment><USER3> I had a good experience writing a little web service in Haskell a couple days ago, an autocomplete server. You give it a prefix, and it returns some number of strings in its database starting with that prefix. I wanted it to be fast, and lighter on memory than the approach some people have been doing with Redis, where they store all prefixes in a sorted set:

<http://antirez.com/post/autocomplete-with-redis.html>

Sounds like a fun toy project, right? I figured I would store everything in a trie, so I could do really fast prefix searches, and then bolt on a REST interface that would send back JSON or JSONP. So I wrote some C code to handle the prefix searching in a JudySL trie (see <http://judy.sf.net/> for details; it's a nice library) and bolted that onto Haskell and wrote some bridge code. What I ended up with was a really nice, easy server that took me only a few hours to write, and was every bit as memory-efficient as I'd hoped. Source code here, if anybody's curious:

<https://github.com/PeterScott/acdaemon>

The learning curve on Haskell, though, is really something. If you really want to see something ridiculous, try looking at the auto-generated library documentation for anything involving regular expressions. The type declarations in Text.Regex.TDFA are like something H. P. Lovecraft might write about.

<comment><USER4> It's a fair point about Haskell's learning curve. Haskell is different enough from the languages most people have grown up using that--at least in my experience--there are times that simply understanding a few lines of code can take minutes.

On the other hand, that fact has always seemed to me a mark of why it's worthwhile to persevere: as when you are learning mathematics, things can seem entirely opaque until they 'click', but then you've really made an advance in your understanding.

Probably most people are aware of it, but the O'Reilly book _Real World Haskell_ by Bryan O'Sullivan, Don Stewart, and John Goerzen, is a great way to get started. The book is on-line at

<http://book.realworldhaskell.org/>

Chapter 8 discusses (one of) the Haskell regexp implementation(s), and in particular addresses one of the puzzling aspects: polymorphism in return type. The whole book is excellent.

(I should also point out that another book _Learn You A Haskell_, has just been published, and is well-regarded. I think it assumes rather less programming experience than RWH, and also covers less of the "real-world" aspects. It also can be read on-line, at

<http://learnyouahaskell.com/>

and in fact there is a coupon code on that page now for 40% off.)

Also, the Haskell community is, in my experience, extremely helpful and welcoming. People should come and join!

<comment><USER3> The place where I've seen Haskell really shine is parsing. Parsers are remarkably easy to write in Haskell, thanks to Parsec and its various spinoff libraries. For example, here's a minimal HTTP request parser that Bryan O'Sullivan wrote by essentially translating part of the RFC into Haskell:

[https://bitbucket.org/bos/attoparsec/src/tip/examples/RFC261...](https://bitbucket.org/bos/attoparsec/src/tip/examples/RFC2616.hs)

It's 54 lines long, pretty trivial, and here's a really cool part: it parses incrementally on strict bytestrings, so you can just do raw socket recv calls and pass the chunks of input to the parser. Similarly, I wrote a parser for the subset of YAML that beanstalkd uses (as part of the hbeanstalk client library), and it was just 11 lines of code. It's very impressive.

(The concurrency and parallelism stuff is also notably slick, but I haven't had as much occasion to use it. Haskell's aversion to side-effects really pays off sometimes.)

By the way, you're right about the Haskell community being friendly and welcoming -- as you yourself demonstrate. :-)

<comment><USER5> The HTTP request parser doesn't look readable or trivial to me at all.

I'm not familiar with Haskell, so to me the code looks like a mix of high- level declarative and low-level specialized constructs (e.g. skipWhile, takeWhile) interleaved with syntax noise. And it seems to be using quite a lot of external libraries. Also, correspondence of the code with the HTTP spec is completely non-obvious.

In contrast, here's an HTTP response parser I wrote in OCaml using just one library: [https://github.com/alavrik/piqi/blob/master/piqi- tools/piqi_...](https://github.com/alavrik/piqi/blob/master/piqi- tools/piqi_http.ml) (see lines 26 - 218).

I've just noticed that the code you are referring to is an example. Well, looking at the example, I can hardly come to a conclusion that Haskell shines for parsing.

<comment><USER3> If you don't know Haskell, and you've never used attoparsec, then I'm not surprised that you don't find that code to be particularly clear or readable. Haskell has a steep learning curve, as I said earlier. This is not a very damning criticism of Haskell's suitability for writing parsing code.

By the way, that long import list is actually just importing some basic stuff from the standard library, and the attoparsec parsing library. One of the persistent minor annoyances of Haskell is writing long lists of module imports.

<comment><USER5> Fair enough. I didn't mean to criticize Haskell. In fact, I'm planning to learn it.

I was just surprised that this code was presented as a good example of Haskell's fit to the parsers domain. It would be interesting to see if my perception of this code changes once I get more familiar with the language.

<comment><USER6> I write a lot of ocaml code (for money, even!) and haven't touched haskell for about four years. I still find the haskell version here easier to read. I imagine what's tripping you up is the operator soup. Whilst ugly (one of the things that turned me off haskell) it is a lot easier to read once you are familiar with basic haskell typeclasses (applicative, functor etc). That said, the ocaml version could definitely be a lot nicer. Check out eg

Yojson (search for 'let positive_int') <http://forge.ocamlcore.org/scm/browser.php?group_id=153>

Mirage (using MPL for zero copy parsing) [https://github.com/avsm/mirage/blob/master/lib/net/direct/mp...](https://github.com/avsm/mirage/blob/master/lib/net/direct/mpl/protocols/ethernet.mpl)

<comment><USER5> Hi there! I do quite a bit of both OCaml and Erlang.

In fact, I borrowed Yojson's json parser for my project (piqi.org). Also, I'm familiar with MPL. It looks very nice, but from what I heard it is fairly immature. And you definitely can't parse HTTP this way :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Could someone comment on Haskell in comparison to Erlang, Clojure or Scala? I felt like when I started choosing between Ruby on Rails and Python/Django, they were so similar that choosing either one would be a fine choice. Now that I'm interested in functional languages too, it seems that comparing Haskell to Erlang is just not the same as Python to Ruby.

<comment><USER8> They're so different and yet so similar it's probably best taking them one topic at a time. I've written nontrival things in all of those except clojure, but I think I still have a pretty good idea what it's about from a bit of playing around, reading the notes of others, time spent in PLT Scheme etc. I hope this is helpful for some people looking to dive in--remember, all of this "IMO/IME".

Type Systems:

Haskell and Scala are closest in that they're strongly, statically typed with Hindley-Milner type inference. Erlang is dynamically typed as is clojure. This tends to break the advantage/disadvantage scheme along the same lines as Java/Ruby wrt typing: the former languages generally give you more speed and safety, and the latter languages can do cool tricks with deciding typing at runtime, which can aid in expressiveness.

Type System Complexity/Power:

Haskell has the most sophisticated type system--by far, I think it's fair to say. This adds power but at the cost of a steeper learning curve for people unused to thinking so deeply about the contracts/promises code and data structures are making. Scala's is also fairly involved since it's basically a subset of Haskell's (well, plus traits and inheritance blah)--but not quite as consistent or clear. Clojure and Erlang have somewhat simpler type system that may be more tractable out of the gate--Erlang in particular is pretty straightforward.

"functional-ness", how sharp a break from OOP/imperative is imposed:

Scala is by far the least dogmatic about doing thing in a "functional" as opposed to an OOP or imperative way. Scala's heavy emphasis on seamless interop with Java makes it a sort of up to the programmer to place their style on the continuum between something like Java and something like ML. Haskell, with its purity-by-default, is probably the most opinionated of the group. You will be forced to approach problems very differently. I'd say clojure follows just behind, also having a strong bias toward doing functional-only styles. Erlang is also pretty interested in doing things in a particular way that could be construed as functional (not rebinding names, focus on immutability, for example), but its "big idea" is more tailored around its flagship library and virtual machine.

Syntax:

Erlang will probably feel the most foreign to a 2011 programmer. Erlang started as a modified Prolog, and the syntactic legacy of Prolog is not widespread in common contemporary languages. Haskell's syntax is rather clean and restricted--though the fondness of veteran Haskellers for custom operators can sometimes be overwhelming for a new programmer. Scala, while a hybrid OOP language that shares many idioms with Java etc, has so heavily dipped into the operator well, even for standard language constructs--the syntax can be a bit crowded. Imagine Java with twice the non-alphanumeric density. Clojure is a LISP, so it's very clean and clear syntactically, provided you are a parenthesis master or make use of SLIME, etc.

Speed (average job, single core, not scalability etc etc):

Haskell, Scala, Clojure, Erlang--descending. Though on certain workloads these players will switch places, as a general rule of thumb that's my aggregated observed performance order in "real world-ish" code scenarios. Clojure is sorta interpolated based on experiences others have relayed to me and online. From a memory standpoint, Haskell is substantially stingier than the rest. This impacts startup times and the practicality of shell tools, etc.

Compilation/VM + Concurrency:

Haskell is alone in this group in that it compiles to native code--well, at least, the most commonly-used configuration does: the compiler ghc. GHC is a beauty of a project. Very good native code generation, aggressive improvement projects (new I/O manager, LLVM backend) incredibly advanced concurrency capabilities (sparks, first class green threads, seamless async IO). Erlang uses a VM, beam, which also uses green threads (which erlang calls processes) and transparent async I/O--but, erlang goes even further to provide syntactic support for super-efficient message-passing between these processes, and facilities to transparently pass those messages between machines in a cluster. Clojure and Scala both use the JVM. It is what it is--mature, fast, but primarily designed for Java and things a lot like Java. Cool features like tail call optimization and green threads are simply not possible b/c the JVM does not (currently) support them. (I know Scala has Actors, Akka, etc, but JVM-based actors are not in the same league as what Erlang and Haskell have.)

All of these languages have a REPL, thank god.

Breadth of Libraries:

The JVM languages here obviously have a HUGE wealth of libraries available. The only concession is calling them can be somewhat awkward and "downgrade" you out of the functional idioms you'd rather be using, depending on the library. Haskell's library situation is pretty good (Hackage has libraries for most everything you need and is growing quickly every day), and Erlang is probably bringing up the rear, here. OTP is excellent, and there are many libraries related to large networked systems etc, but not as much "general" coverage.

Key Strength:

If you want to write high-uptime distributed systems, Erlang/OTP is the bees' knees. Everything about the language and runtime is tailored to that environment--supervisor trees, mnesia, good scheduling of hundreds of thousands of lightweight processes.

Haskell is great at correctness. Like its non-lazy cousin ML, if you satisfy the type system, a shockingly high percentage of the time your program is just flat out correct the first time you run it. Haskell is also pretty darn good at single-machine multicore concurrency.

Clojure is a great "modern Lisp". Many of the concerns, fairly or unfairly, leveled at Lisps in the past (no libraries, stagnant platform, closed development, etc) are non issues. Building on the JVM enables a very small developer core to make progress on the language while leveraging a mature platform that evolves independently and at scale.

Scala is a "better Java". While iterop with large Java-oriented frameworks is _possible_ in Clojure, it's pretty much trivial in Scala. You can dip a toe incrementally into the functional world while keeping retaining your existing projects, favorite libraries, 3rd party frameworks, etc--transitioning as fast and far as appropriate.

Summary:

The good news is, all of these languages are pretty damn good, and all of them actually have healthy, thriving developer communities and razor-sharp maintainers.

If someone has never done functional programming before, I'd personally recommend trying something like clojure or Racket first to get the fundamentals down before digging into something truly mind-bending like Haskell. Scala is probably not a big enough leap to discipline yourself to grok functional just b/c it's so easy to relapse into non-functional patterns and Scala will happily comply.

<comment><USER9> For correctness, both Haskell and Erlang have Quick Check, which is simply fantastic. Quick Check is somewhat easier to use with stateless code, which favours Haskell over Erlang.

<http://www.cse.chalmers.se/~rjmh/QuickCheck/>

<comment><USER10> For more correctness, scala has had interop hiccups

<http://lampsvn.epfl.ch/trac/scala/ticket/2991>

[http://stackoverflow.com/questions/3313929/how-do-i- disambig...](http://stackoverflow.com/questions/3313929/how-do-i-disambiguate- in-scala-between-methods-with-vararg-and-without)

(and does Orig. Commenter have examples of clojure hiccups? Interop is _very_ important to both (and F#). Maybe a more meaningful compare/contrast is haskell, scala and F# (which I can't do)

<http://matt.might.net/articles/best-programming-languages/>

\</comment></comment></comment></comment><comment></comment><comment>---

<http://james-iry.blogspot.com/2010/05/types-la-chart.html>

(his league table of "Most Powerful Type Systems": Agda, epigram, scala, haskell

</comment><comment><USER11> Hm, this isn't such a good recommendation.

<http://snapframework.com/>

(Right now there's an internal server error.)

<comment><USER12> Maybe you sent it the wrong type of request :).</comment></comment>


How Healthy Is Soylent? - <AUTHOR> http://www.theatlantic.com/health/archive/2016/07/soylent-is-healthier-than-our-diet/489830/?single_page=true <comment><USER2> This article mixes up "nutritious" and "healthy", and they're not the same thing. It's very likely Soylent is terrible for you, but we won't find out for a few decades.</comment>


Flaws in the clinical trials for Gardasil made it harder to assess safety - <AUTHOR> https://slate.com/health-and-science/2017/12/flaws-in-the-clinical-trials-for-gardasil-made-it-harder-to-properly-assess-safety.html <comment><USER2> I wonder if any efforts have been made to conduct a deep review of clinical trials to see if there are patterns of protocol design that are likely to lead to underreporting of adverse effects.

As (unfortunately) a user of a number of prescription medications, I have encountered adverse effects that were considered uncommon, yet heard about similar issues from fellow users. Of course, this is anecdata, so one can draw no conclusions, but I have a nagging suspicion that enough digging by people who truly understand statistics will find flaws, perhaps major ones.

Not likely to happen, though.

<comment><USER3> There are a number of reasons why problems can slip through clinical trials, even with proper clinical trials design.

Some side effects are extremely rare, so rare that even with "large" clinical trials groups the problems don't occur. Or they might occur, but at rates no greater than what the placebo group experiences. Some side effects only show up with repeated long-term use of a drug. That's why there exists "post approval monitoring" to watch for these problems. Some side effects only show up when a drug is taken concomitantly with other drugs. Some side effects only show up when users have certain diets. Some side effects (and some efficacies) only show up for certain ethnicities and sub-populations. Some side effects only show up when patients take much larger doses than were tested in clinical trials.

Larger statistical samples would help to reduce these problems, but it's often not as easy as you might think to recruit large numbers of people for your study. First, it is quite expensive to put a large test group together. Some diseases / conditions are quite rare, so it can be difficult to even find enough people with the condition. As the test runs through, some fraction of the participants will drop out for one reason or another. Some people will just stop taking the medication for one reason or another. How you treat these "dropouts" is not a simple question and can have a huge impact on your clinical trials conclusions. Some test measures are highly subjective and experts will disagree on how efficacious / dangerous a drug is when presented with the same exact data.

The bottom line is that drug approval is extremely complicated. Better test design and monitoring helps but it will not catch all problems. Regulators have to balance safety with benefits in the face of uncertainty.

</comment></comment><comment><USER4> >> Not owning up to that uncertainty, when it is legitimate, likely will only slow scientific progress. In the controversial realm of vaccines, it will also create fodder for conspiracy theorists spreading overblown or unfounded fears among an already distrustful public.

Just when did "the realm of vaccines" become "controversial"?

Also, one thing I couldn't figure out from the article is whether Lyng and the other women who suffered after taking part in the vaccine trials actually received the vaccine, rather than a placebo. Is that information even recorded?

</comment><comment><USER5> On conflict of interest during Gardasil's testing in India: [http://www.corpwatch.org/article.php?id=14401](http://www.corpwatch.org/article.php?id=14401) "JayaJan Pharmaceutical Research in India was one of the companies with which Merck had a contract to test Gardasil. Like most of the industry, Merck increasingly outsources its clinical trials to Contract Research Organizations (CROs) in areas of the world where trial subjects are plentiful, operating costs are low, and regulations lax. .. Critics point out that CROs can come with built-in problems. Conflicts of interest can arise when CROs are paid royalties only after a drug is approved rather than being paid a set fee that is independent of how safe or effective the drug turns out to be. Problems can also arise because CROs know that favorable findings mean that research into a test drug will continue, and they may also believe that results that please the hiring corporation can lead to future contracts. "[C]ompanies know that the farther the compound moves through the research cycle, the more money they can raise," Nature reported."

Also on India and a Gardasil Supreme Court case questioning safety: [http://sanevax.org/india-supreme-court-hpv-vaccine- controver...](http://sanevax.org/india-supreme-court-hpv-vaccine-controversy- continues/)

And from Mercola questioning its effectiveness: [https://articles.mercola.com/sites/articles/archive/2010/12/...](https://articles.mercola.com/sites/articles/archive/2010/12/29/why- india-has-stopped-giving-hpv-vaccines.aspx)

In general from Marcia Angell: [http://www.nybooks.com/articles/archives/2009/jan/15/drug- co...](http://www.nybooks.com/articles/archives/2009/jan/15/drug-companies- doctorsa-story-of-corruption/) "The problems I've discussed are not limited to psychiatry, although they reach their most florid form there. Similar conflicts of interest and biases exist in virtually every field of medicine, particularly those that rely heavily on drugs or devices. It is simply no longer possible to believe much of the clinical research that is published, or to rely on the judgment of trusted physicians or authoritative medical guidelines. I take no pleasure in this conclusion, which I reached slowly and reluctantly over my two decades as an editor of The New England Journal of Medicine."

<comment><USER6> I feel like a lot of people on HN don't want to promote "vaccine denialism," but the reality is that you cannot put all vaccines, nor can you put all drugs, in the same category.

Many vaccines have done a lot of good. Many of the people who question some of the more recent vaccines are not against the standard MMR.

I don't think it's wrong to question newer pharmaceutical products, including drugs, devices and vaccines. Remember Vioxx?

Clinical trials have a lot of safeguards, but we've seen how business interests can side step these. A lot of money goes into studying new compounds. If during the animal trials, if a single monkey dies, your entire compound is often scraped and has to go back quite a but. At the human side of testing, potential issues can mean a lot of money being scrapped.

It's a bigger problem with how we develop drugs, and it's also a bigger problem with how we see science, especially the mixture of science and funding. James Corbet has a great video about the "Weaponization of Science" which is worth considering: [https://www.youtube.com/watch?v=yecefLsE44U](https://www.youtube.com/watch?v=yecefLsE44U)</comment></comment>


Darcs - Another open source version control system - <AUTHOR> http://darcs.net/ <comment><USER2> The primary pull of the "patch theory" is that it will allow you to share code more easily between different "patch sets" (branches / forks). The reality of software projects means that you can't automate such a process except in the most trivial cases, and other VCSs handle the trivial cases already.

You can imagine that I write a new filesystem for Linux, but I wait two years and the FS interface has changed drastically, the old patch is meaningless. If the patch is sufficiently independent textually, then Darcs lets you reorder it anywhere you see fit, even if you know that doesn't make sense. You have detailed knowledge of the system, Darcs doesn't.

By contrast, Git/SVN/Hg folk think about snapshots of development. So it's a different paradigm.

But the snapshot paradigm is almost always the most useful paradigm, since every snapshot in history (unless you rebase) is going to be one that was actually vetted by a real programmer. Reordering patches throws away the valued _actual snapshots_ that you were working with in favor of automated reconstructions of what a snapshot _might_ have looked like _if_ you had been programming in that order.

Of course, you can always do the same dangerous things with Git and rebasing.

<comment><USER3> What you can't do with git is pull a set of related patches when you have not created a branch for them. Which is apparently useful, as git has cherry-pick for that, and rebase.

Except, cherry pick will only work for "in air" commits, and rebase requires you to review all the commits.

darcs will happily pull a set of related commits knowing the relations between them. You may have detailed knowledge of the system so in some cases you may do something better than what darcs does, but that does not mean you should be resolving merges and commit dependencies by hand all of the time.

Honestly, I have not used darcs in years, but that is the "right" thing I expect from a VCS, and it has no downsides per se[0].

[0]they may be in darcs implementation, or possibly in the theory, but definitely not in the feature

<comment><USER2> Rebase only requires you to review the commits to the same extent that merge does, unless you're doing an interactive rebase.

Honestly, I expect the differences between Darcs and Git in terms of rebase / interactive rebase / cherry pick / merge to be a matter of implementation. Both systems are fed the same input, both track enough of it, so both could theoretically provide the same output. (I think Darcs is a little better at it, but every merge should be done with a watchful eye in either system.)

But I get the feeling that the patch-centric model is encouraging users to play fast and loose with patch order. If you wantonly reorder patches, you might get a sequence of unusable code bases culminating in the current working version of your software. It's easy to move a patch that uses a feature to a point before the feature is introduced.

Basically, the claim that "Darcs automatically groups changes which depend on each other" is one that I can't take seriously. How can it know which changes depend on each other, if (for example) they're in different files? By comparison, I hear from the Git folk advice along the lines of, "Be careful with rebase, because it is a destructive operation".

And because Git is snapshot-centric, if the app crashes in testing you can look at the SHA-1 used for the build to check out the exact tree used for the build, even years later, if necessary. No tagging required.

<comment><USER4> Git actually doesn't track cherry-picks, at all, and that's been a huge problem for us.

Consider for example, having two branches: "stable", "master" which have already diverged. Fixes go into "stable" and are regularly merged into "master".

Now imagine someone writes a fix F, which must be applied immediately to both "stable" and "master" and can't wait for the regular merge effort.

So with git, you just cherry-pick F into "stable" and "master".

Now, someone who uses "stable" discovers a big flaw in F, and reverts it. They assume their work will be merged into "master" as usual.

Then, a merge from "stable" to "master" happens, and the merge sees that the "stable" branch has 0 changes w.r.t F (commit+revert), whereas it has the F change in "master". Git's merge algorithm will consider this a trivial case, and _do the wrong thing_. The merge result will have the broken F application in "master", and there will be _no conflict_ or any indication of a problem! This has been a huge problem for us.

So the result of this is that git forces you to either "merge" upstream, or "cherry-pick", but you really should not mix these two modes.

If you only use "merge", then the guy who merges must intimately understand everyone's changes in all cases of conflict. If he doesn't, others must help him resolve the conflicts _on his working directory_. Then, the merge result is one monolithic commit that makes understanding changes very difficult.

If you only use "cherry-pick", then you lose tracking of which changes have already been merged upstream, and which haven't. You start relying on the grep of "git log", which is unreliable, and you have no reliable tools to automate this. "git cherry" is unreliable and has plenty of false negatives/positives. Then there are of course problems with patch dependency, where you have to figure it all out on your own.

In short, the snapshot model is _very_ problematic here. None of these problems would occur in the darcs model. Unfortunately, darcs does not scale. Whether that's inherent or not, I don't know. But if it did, I know I'd definitely prefer to use darcs in a large collaborative effort than git.

<comment><USER5> If I understand you correctly, your problem would occur if, say, you were maintaining 1.0 and 2.0 branches of a product and needed to apply the same bugfix to both; you can't merge, so you cherry-pick.

Surely this is something that the Linux project runs into constantly? I wonder if they have a solution?

<comment><USER4> In the case of two maintenance branches (1.0, 2.0) you're probably going to use only cherry-picks, and no merges, and just manually track what you've already cherry-picked.

In our case, we had the "bleeding edge" branch (master) and a maintenance branch. Fixes generally go into the maintenance branch and then are merged upwards. But we allowed "emergency patches" to be cherry-picked upwards (or downwards) too. The combination is the problem.

If we had stuck to just cherry-picks or just merges, we would not have this problem. But as I also explained, sticking to one of the approaches has severe drawbacks too.

</comment></comment></comment></comment></comment></comment><comment><USER6> I like to think of Darcs as the PostgreSQL of distributed version control. They both have correctness as their first priority, sacrificing a little performance as necessary. PostgreSQL was very slow at first but it is closing that gap, and I think the end result is better for it. Git and Mercurial sacrifice correctness in favor of pragmatism in some cases, by taking shortcuts such as three-way merges.

Unlike in the relational database world, there is no accepted standard for interfacing with a versioned repository. It remains to be seen whether Darcs, like PostgreSQL, will eventually gather enough steam to build a substantial user base.

<comment><USER7> I always thought the correctness aspect of Darcs was very weak, from what I remember most of the original "patch theory" wasn't sound

<comment><USER8> Yes, the original theory was weak and not sound, but they worked on it. There is some initial work towards Coq formalization.

<http://wiki.darcs.net/Theory>

</comment></comment></comment><comment><USER9> Darcs is not "another", it is "the first distributed" version control system that gained some traction in open source projects. Before git usage exploded, darcs was almost exclusively used by haskel and lisp libraries.

What killed darcs, besides performance issues with darcs 1, was "one repo one branch" mode, and tedious way of maintaining long lived forks, which wasn't that convenient as what git provides.

However, I'm glad that Darcs is still actively developed and used, since it has very nice theory and model behind it, and it still has some very useful concept which are quite unique for it.

<comment><USER10> > Darcs is not "another", it is "the first distributed" version control system > that gained some traction in open source projects.

Wasn't BitKeeper in use by the Linux kernel for several years before Darcs came out?

<comment> loup-vaillant > "that gained some traction in open source projects."

Therefore, proprietary tools don't count.

</comment></comment></comment><comment><USER11> The Cambrian Explosion of the distributed version control system has passed I think. Git seems to come out ahead. I think it would be easier to just switch to it.

I like Bazaar and used Hg, but this is tool used to collaborate with others (unlike say an editor) so picking a tool that others know and use is important in a team. Darcs has an interesting approach, sure, but that is not enough for it to win mind-share, and I wouldn't spend time looking at bit because I will have a very hard time getting others to do the same.

Also the excitement and euphoria about learning and experimenting with distributed VCs is passed. I feel, for most they have stopped having the "wow" factor and became just a tool in the same category as patch, diff, less and tar.

<comment><USER12> It's a sad day, the day a hacker refuses to look at something because they'd "have a very hard time getting others to do the same". By that same token we should avoid looking at the likes of Haskell, Erlang, Rust, etc. You are absolutely right that Git has come out on top, but Darcs definitely merits a look at least.

For what it's worth, I was in the Monotone [1] camp against Darcs back in the day... :)

[1] <http://en.wikipedia.org/wiki/Monotone_(software)>

<comment><USER13> This. Surely git "has won", but you'd be fitted with a pretty bad sense of history if you think that this is forever. Thus, it definitely does not hurt to keep Darcs in view.

I bet that if any version control system is going to replace git, it'll look at least as much like Darcs as anything else.

I'm no expert by a long shot, but to me it appears that if we're going to try to _finally_ make version control user-friendly, something inspired by Darcs' patch algebra may well be at the base of it. While Darcs is impractical for a whole set of use cases, it's _very_ practical for a whole other set of use cases.

<comment><USER14> It will be very hard for Darcs (and Bazaar, Monotone, etc.) to get so much better than git that switching is worth it. Just a better theoretical base for some edge cases is not enough.

Hg has also quite some mindshare. I consider it the only DVCS, which still seriously competes with Git. Apart from that, there are niche groups: Haskell with Darcs, Ubuntu with Bazaar.

<comment><USER15> Fwiw he didn't say Darcs will replace git, he said that whatever eventually replaces git will likely implement some of Darcs best features like the patch algebra.

Hence, it's worth taking a little time to actually understand those features, even if you never use darcs. Plus the mental exercise and learning something new is valuable in and of itself.

</comment></comment></comment></comment></comment><comment><USER16> For those interested Linus' comments on Darcs from 2007 <http://markmail.org/message/vk3gf7ap5auxcxnb>

<comment><USER3> notice that in this message linus says "And in that sense, I do think the two approaches can _complement_ each other"

And simmetrically, a few years later, david roundy (the original author of darcs) started working on iolaus[1] which is in fact a darcs-ish implementation on top of git.

[1] <https://github.com/droundy/iolaus> now abandoned I believe

</comment></comment><comment><USER17> I used darcs for all personal repositories for a couple of years. It has a great UI, but I ended up moving to git for two reasons - a) most projects I was working on with other people were using git, and b) there was nothing like github for darcs (and still isn't as far as I know). It was really nice while it lasted though.

<comment><USER18> Darcs is good for personal use, but I moved away primarily because of the exponential merge problem. I think darcs2 takes care of it in most of the cases but NOT always. That is a big question mark for production repository. Darcs is easy to get started with though - to anybody interested I recommend this link - <http://blog.interlinked.org/tutorials/darcs.html> .

On the other hand if you want to move from darcs to git , use the following - <https://github.com/purcell/darcs-to-git>

<comment><USER19> I'll just add that these days, people should consider using the Darcs bridge instead: <http://wiki.darcs.net/DarcsBridgeUsage>

It's not ready for bi-directional incremental bridging, but for one shot conversions, it should be just fine.

The Darcs bridge uses the Darcs library to do things and understands Darcs better.

</comment></comment></comment><comment><USER20> "Another" could imply that Darcs is new, but it's not. According to Wikipedia, the first release was in 2003.

We tried using Darcs at work in 2006, but the early exponential merge issues made it impossible to use. (One time, we let Darcs try to merge "some changes" over the weekend, but it never completed.) Unfortunately we chose Subversion instead.

<comment><USER21> Ack, Darcs had a problem so you went with SVN? I hope you've at least switched to using git as your SVN client by now.

<comment><USER22> Does git-svn now handle svn:externals properly? I can't find anything saying it now has support. I'd love to switch to git as my client, but we have upwards of 70 externals for libraries we maintain, and converting those to git submodules is not an option. Well it is, but it is far more work than simply using git as a client.

<comment><USER21> I don't know. But when choosing a system I wouldn't chose SVN for svn:externals. Git has submodules which I find nicer.

<comment><USER22> I don't think Git submodules were added until 2009 (at least that's what the commit history looks like). We deployed with SVN at least six years ago, long before git could compete.

Still, I would like to use git as my svn client, but it's just not a suitable replacement without externals handled nicely.

</comment></comment></comment></comment></comment><comment><USER19> Hi all! As a Darcs developer (mostly cheerleader), I'd like to make a general comment that Darcs should be seen more as a version control system we're trying to build than one you should use right away. Please keep an eye on it if you're interested in the idea, but don't encourage your boss to use it just yet :-)

It's made a lot of progress over the years, and works great for my needs, but we do still have serious bugs and performance problems we need to sort through; and yes still lacks a lot of critical tooling/infrastructure around it.

We love what we do, and think that we have something new to bring to the table (among other things, making it easy to pinpoint commits that you want to pull, delete, etc; DVCS'es may all do some cherry picking ala git add -p, but Darcs makes it possible to use it everywhere), but it may take us a _very_ long time to get to stage where we can responsibly talk about it.

There lot's of work to do, lots. If you're looking into getting to some Haskell hacking, consider Darcs as a good side project to get into. We can use you.

<comment><USER23> I'm a Darcs user and occasional contributor. I have been using it continuously on small-medium projects to my great benefit since at least 2004. Now we have just released 2.8, the developer community has been growing, and sure Darcs has its problems but so does every VCS. We also have unique strengths. Is it really necessary to still be saying "we're not ready" and "don't use it yet" ?

I would like to see hard data and experience reports of where Darcs worked and didn't work for people, instead (so I'm loving this thread.) Here are a couple of repos I've worked with:

\- hledger: 2477 patches, 251 files, 66M, 5 years of activity

\- Zwiki 0.x: 1897 patches, 295 files, 12M, 5 years

\- Darcs: 10171 patches, 731 files, 51M, 10 years

\- GHC before it moved: 23413 patches, 1353 files, 162M, 5 years (+ 10 years of converted history)

Here's the darcsstat script that reports these numbers: <https://gist.github.com/2653180>

</comment></comment><comment><USER24> A quote from the darcs wiki:

This is why darcs currently doesn't always works so well for keeping a "local branch" of some source. The local deviations are likely to cause exponential conflicts after time. Local deviations must either be isolated in some way (kept in separate files) so they never conflict, or changes from upstream needs to be merged in "by hand" and recorded as local patches that doesn't conflict with the local changes.

Can anyone help me reconcile why I would give darcs a try over git if I can't do local branching?

<comment> loup-vaillant My guess would be, because you don't need to.

First, you can do "local branching" by cloning your repository. On a local filesystem, `darcs get` is fast (uses hard links). And instead of `darcs branch`, you use `cd` (personally, I don't see how `cd` is worse, do you have some pointers about that?).

Second, the Darcs way of managing patches gets you "spontaneous branches". <http://wiki.darcs.net/SpontaneousBranches> The main advantage lies in that you can select the patches you push to other repositories. Say you work on some feature. Suddenly you need to fix a bug. The way to do it is, fix the bug right away then send the relevant patches (easy if you name your patches sensibly). Your unfinished feature simply won't get send (unless of course there's an actual conflict).

<comment><USER24> I see your point about local branching, but I do prefer git's approach for simplification on large branch sets. Some of the git repos I work with have upwards of 200 branches, having those in folders to be manually managed would be a little overwhelming.

</comment></comment></comment><comment><USER25> I had the pleasure of using Darcs in an open source project some time ago. Can a long-time Darcs user explain to me what I was doing wrong?

The build for the project had passed on most platforms, but on one platform in particular (the one I was interested in), the build agent started failing on a particular day a month before. Being able to determine which commit a build started failing at has a great deal of real engineering value, but I couldn't figure out a way to do that with Darcs. The patches are ordered in the repository according to Darcs' own preference, and they're dated according to when they were committed locally, not when they were pushed.

I discussed this point with someone else and they said, to paraphrase, "usually, I know which of my patches has caused a problem, so this is a non- issue." It wasn't a non-issue in this case, of course, because _I_ didn't know which of his patches had caused the issue, and no one else had cared to figure out why this third-tier platform wasn't building.

Is there any way at all to characterize what exactly a build machine is building at a particular time with Darcs? With perforce and subversion, there's a commit number. Git has a commit SHA hash. What can you do in a build agent to log exactly what is and isn't being built with Darcs?

<comment><USER19> Hi! I'm sorry this isn't any easier yet. In Darcs, one approximation of this sort of thing is to take the whole history (sequence of patches) and hash that. Unfortunately, this approach fails to recognise different darcs-allowed patch orders as having the same history. It's fine as a conservative default, but we'd like something better. See [short secure ID](<http://wiki.darcs.net/Ideas/ShortSecureId>) for some thinking about the problem.

</comment></comment><comment><USER26> Perhaps darcs' most prominent user base is the guys who work on GHC, the Glasgow Haskell Compiler. They still use it, but have not been completely happy: <http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation>

<comment><USER27> Actually, GHC has been using GIT for about a year now. There was a lot of discussion but darcs has (mostly) been dropped. There are a few libraries that are still darcs-controlled but generally because nobody has got round to migrating them I think...

</comment></comment><comment><USER28> How does darcs compare to git these days? I know it used to have some significant performance issues on large repos.

<comment><USER19> It still does.

We've made a lot of progress. You'll see people saying that their performance problems have gone away. But we have a long way to go.

Two things to fix: downloading repos is slow (latency, too many small files); and conflict merging can be slow under a few cases. The first one we have a fix for from a summer of code project, but needs more work. The second issue is a very deep, very serious, and will take us a seriously long time to think through.

</comment></comment><comment><USER29> It is weird that all the comments are about patch theory. I use darcs because it is by far the easiest, simplest to use DVCS. I don't know anything about patch theory, and I don't care about it at all. I just know I can have a DVCS noob using darcs effectively in a couple minutes, and it will merge properly.

</comment><comment><USER30> Darcs is pretty nifty, but until the atomic patch theory has been verified, I'm happy to stay with git.

<comment><USER31> Are you expecting git to be verified soon too?

<comment><USER24> git's only "theory" that could potentially be verified is merge resolution. which has been.

I think darcs approach is a little different.

<comment><USER31> git has plenty of properties that are supposed to be true. The developers write tests for them. The properties being tested could be proven instead.</comment></comment></comment></comment>


Show HN: Use tools you already know to research 5000 destinations - <AUTHOR> http://tripsak.com <comment><USER2> It looks like a really neat aggregation of tools. I'm curious why nothing came up when I searched Yellowstone?

<comment><AUTHOR> Thank you! I'm starting with destinations that are cities/towns so not a lot of national parks at the moment (but I constantly add batches of new destinations so will probably be added soon).

<comment><USER2> I didn't realise it was all manually curated - can you get it to automatically search any of the listed sites for the name I put in? That seems like it'd be helpful at least half the time.

</comment></comment></comment><comment><AUTHOR> I made this! Would love to hear your feedback..</comment>


Google Makes Massive Counteroffers To Retain Employees - <AUTHOR> http://techcrunch.com/2011/04/06/google-said-to-have-high-level-mole-at-twitter-makes-massive-counteroffers-to-retain-employees/ <comment> brown9-2 The chances that the players in this game are using careful leaks to TechCrunch, either with real or fake information, in order to make moves against the other players is very high. As readers we shouldn't really trust that what Twitter sources tell TechCrunch is totally legit, or the same for what Google sources are telling TechCrunch - playing TC or other members of the press in order to help tilt the direction of discussion one way or the other seems like a pretty obvious move.

For example, Google Competitor X sending TechCrunch fake information about Google's desperate-sounding counter-offers helps reinforce the perception of their desperateness.

Also, these two sentences don't really add up:

 _Google may have paid as much as $150 million in stock grants to retain key product employees Sundar Pichai and Neal Mohan, say multiple sources. Both were offered the chief product role at Twitter_

 _Regardless, the fact that large fortunes are being handed out to mid level technical managers is somewhat of a red flag in general._

</comment><comment><USER2> _Multiple sources close to Twitter have said that someone with access to Twitter's most confidential information, such as who they are interviewing for key executive spots, may be leaking that information directly to Google._

This sounds dubious to me. It is not only unethical for a senior Twitter employee to be leaking such information but it is plainly _illegal_. An employee owes a fiduciary duty to his employer to perform his duties strictly for the benefit of that employer. Such an employee also has obligations not to disclose or misuse any trade secret information belonging to that employer. Both of these are pretty serious legal obligations, the violation of which would subject not only the direct malefactor to major liabilities but also anyone conspiring with him to commit the wrongs.

This story, then, assumes that Google is effectively engaged in knowing illegal acts of the most serious kind. While that in theory _might_ be true, it assumes that (1) Google has a company ethic that would tolerate such willful misconduct, and (2) Google would be stupid enough to engage in a course of conduct that could pretty readily be exposed, much to its injury in law and in reputation.

This doesn't ring true for me.

In addition, grants of conventional restricted stock are in fact _sales_ of stock to a recipient. That means someone has to pay for them. Assuming the Google stock here is being sold at fair value, that is one hefty price tag for an employee to pay. Of course, a board of directors might authorize payment by a loan to the employee but that loan would need to be full-recourse in order not to create inordinate tax problems for the company. This means that the employee would borrow, in one case, $100 million, and, in the other, $50 million, on terms for which he can be personally sued for failure to pay. And what would the employee get for his $100- or $50-million price tag? Well, in the normal course, stock worth just that. So where is the bargain for the employee? Even with a discounted price, the risk to the employee would be enormous because the deal would effectively be a bet that Google's stock will increase significantly in value before the stock vests and the payment comes due. Again, this doesn't really make sense. CEOs take such bets with restricted stock on occasion when a company is still fairly young (e.g., Meg Whitman with Ebay), but this is unheard of for an engineer employee, even a high-level one.

A deal of this type could be structured with stock options that would not need to be paid for up front and would not result in a tax hit or payment obligation to the employee upon grant. But this piece specifically uses the term "restricted stock." Perhaps this is not really restricted stock proper but some sort of restricted units that mimic stock but really constitute contingent employee bonuses. But the piece is suspect in its confident assertion that "restricted stock" was used.

Finally, there are the public company implications. Whenever a company incurs a material event, it must be publicly reported in fairly short order in SEC filings. A $150 million outlay? That would seem material even for Google.

Then there is the question of board of director responsibility. Directors have fiduciary duties to adhere to in making stock grants. How would the Google board justify these grants? And how could they justify them based on illegal "tips" received from a Twitter employee.

I may be missing some nuances here, as my firm does not often get deeply into fine points of public-company law. On its face, though, this one does not add up when the legal factors of which I know are taken into account.

<comment><USER3> _Whenever a company incurs a material event, it must be publicly reported in fairly short order in SEC filings. A $150 million outlay? That would seem material even for Google._

No it's not - employee compensation is an ongoing expense. You don't see Goldman Sachs doing disclosure everytime someone gets a bonus!

Anyway, Google discloses stock grants every quarter.

 _Stock-Based Compensation (SBC) – In the fourth quarter of 2010, the total charge related to SBC was $396 million, compared to $276 million in the fourth quarter of 2009.

We currently estimate SBC charges for grants to employees prior to January 1, 2011 to be approximately $1.6 billion for 2011. This estimate does not include expenses to be recognized related to employee stock awards that are granted after December 31, 2010 or non-employee stock awards that have been or may be granted._

[http://investor.google.com/earnings/2010/Q4_google_earnings....](http://investor.google.com/earnings/2010/Q4_google_earnings.html)

<comment><USER2> OK, point well taken. Thanks for the correction.

</comment></comment></comment><comment><USER4> This isn't an April Fools post is it? I mean seriously, if you're willing to pay $50M or $100M to keep a single employee from walking, what happens if they die on their commute into work? What sort of risk are you carrying anyway?

And I didn't think I could be amazed by 'Google scale' any more, sure proves I was wrong on that.

<comment><USER5> I'm wondering if they failed to check the date on the email of their tip-off.

Extraordinary claims require extraordinary evidence.

I might be mistaken but I believe Sundar Pichai isn't an american national, in which case he'll be working on a visa. And in the US work visas require a public declaration of salary (the published data has the names stripped but frankly at a $50m salary I imagine he'd be easy to spot). So come paperwork renewal time we'll be able to see exactly how accurate TC are...

<comment><USER6> I like where you're going, but it mentioned it was $50MM in stock, not salary.

<comment><USER7> I would like to believe that the US visa laws are insufficiently moronic to be defeated by such a ploy... can anyone confirm?

<comment><USER8> The laws are moronic, confirmed.

I don't know what gave the GGP the idea that salaries are publicly declared in visa filings (which are not public anyway). The laws are not THAT moronic.

<comment><USER9> As far as I know, salaries _are_ included in H1B visa database. Ah, here's the article where somebody mined it for game developer salary: <http://realtimecollisiondetection.net/blog/?p=107>

<comment><USER10> A company hiring H1-B workers must show that they're paying average+ wages for the position [1]. They need not disclose actual salaries paid to individuals, nor are they precluded from paying above market rate.

1\. <http://en.wikipedia.org/wiki/H1b>

Employers must attest that wages offered are at least equal to the actual wage paid by the employer to other workers with similar experience and qualifications for the job in question, or alternatively, pay the prevailing wage for the occupation in the area of intended employment, whichever is greater.

<comment><USER5> Looking at the H1B dataset it includes two fields "proposed wage rate" (what the company proposes to pay the candidate) and a "prevailing wage rate" (the market rate).

I believe companies are also required to disclose to this information to other employees on request (to provide a check that H1Bs aren't being used to replace employees with lower salary staff)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> $50m in outright stock grants vested in only two years for a product VP?

Not really passing the sniff test for me.

</comment><comment><USER12> Let's see how crazy this is or isn't. From [http://www.google.com/finance?client=ob&q=NASDAQ:GOOG](http://www.google.com/finance?client=ob&q=NASDAQ:GOOG) I see that Google has a market cap of $184.61B. According to <http://en.wikipedia.org/wiki/Google> Google has $46.24B in equity, and 24,400 employees.

Equity tends to add to market cap 1-1, so Google's market cap from ongoing operations and potential for growth is $138.37B. That works out to about $5,670,000 _per employee_. Considering that Google's stock price still reflects a market belief that they will have a lot of growth in their future, most of that market value lies in the actual people. The average Googler is worth millions to Google.

I have absolutely no trouble believing that key employees with a lot of talent and institutional knowledge are worth many times the average. The main thing that is shocking if this story is true is that Google has a good enough understanding of who is worth what to the company that they can properly recognize and act on that fact.

<comment><USER13> ^ Google employee.

<comment><USER12> Actually not a Google employee any more. I left some months ago.

<comment><USER13> Alright. Nevermind then :-)

</comment></comment></comment></comment><comment><USER14> $3.5 million for a key employee I can deal with, but $100 million? It feels like absolute lunacy, if true.

<comment><USER15> If it turns out to be true, I will probably sell my Google stock. I'd always felt that it was a pretty safe holding, but any company that could piss away money like that is not one I want to hold.

<comment><USER16> More to the point, it's not your dividend they're taking, it's a direct dilution of the value of your shareholding. A small tax levied on all other shareholders.

</comment></comment></comment><comment><USER17> "If you're a Google employee and you aren't out interviewing at Facebook, Twitter or Zynga you are a moron"

This is why this has to be false. The precedent would be destructive. How many employees will go out looking for a job to use as leverage, not get a google counter offer, and just leave?

<comment><USER18> Or it could be clever. Google is at a stage in their corporate life where they need people who aren't primarily chasing money. Maybe this is a plan to get those people to leave.

<comment><USER19> Who are you kidding? We are all chasing money.

<comment><USER18> Well, in the sense that we have to have money to survive generally, so we all have to take jobs that pay money, then yes, we are all chasing money. But that doesn't mean we all make the amount of money the PRIMARY determination on where we work and how we spend our time.

Many of us would take a lower paying job if it meant more interesting work, or a better work environment or location, or better long term stability.

</comment></comment></comment></comment><comment><USER20> Usually I go straight to HN comments to read the first few ones to determine if a posted article is worth reading. You guys/gals rock because you help me avoid tabloid stuff and save precious minutes of my life.

<comment><USER21> I didn't think I was the only one.

There aren't too many, or any, other places where you get a peer level of trust from an otherwise anonymous community.

</comment></comment><comment><USER22> Since when did TechCrunch become a tabloid?

<comment><USER23> When they realized it sold more ads + took less time to write the pieces. Then AOL bought them and it became official!

<comment><AUTHOR> well said!

</comment></comment></comment><comment><USER24> _Multiple sources close to Twitter have said that someone with access to Twitter's most confidential information, such as who they are interviewing for key executive spots, may be leaking that information directly to Google. In this case, Google may have acted on that information too quickly. And people at Twitter, say these sources, are steaming mad._

I wonder what google services twitter hiring execs and others use. In the "privacy is dead" age you seem to be able to find out an awful lot about an awful lot if you're willing to go out and piece together public data.And in the realm of open source intelligence gathering, it's unlikely there is a bigger king than google.

I wonder if multiple people at twitter can be found googling the googlers in the days or hours before they meet for a hiring discussion. My money would be on yes, and that's only one of many possible sources.When I was on campus in Redmond a few years ago I was pretty impressed by how tailored the google search ads and even some SERPs in terms of trying to poach from MS.

</comment><comment><USER25> Just call it a pre-emptive talent acquisition. Since both Twitter and Google know that these product guys could go start their own venture, raise $20M, and then sell the team to the highest bidder, they are just preempting the process. Gotta think ahead to overpay talent before your competitor can.

</comment><comment><USER26> Linking to public profiles: <http://www.linkedin.com/pub/neal-mohan/0/278/520> <http://www.linkedin.com/in/sundarpichai>

I would expect a statement from Google on this (whether its an April Fool's joke or not). There is no way they can let their other employees think that 2 guys are making bank here. Its just not sustainable to let employees think that this is the way forward to negotiate salaries

<comment><USER16> I think for share packages that large they'd need to make disclosures to the SEC, wouldn't they?

</comment></comment><comment><USER27> when google poached from microsoft, all ballmer did was throw a chair out the window.

</comment><comment><USER28> If all you get from your job is a (big) paycheck, then you are underpaid.

Yet, I know many artists who stretch their creative souls and struggle financially.

I think there is a happy balance but that is not static, needs to be readjusted as life unfolds, from young whippersnapper programmer to family comes first tech lead.

</comment><comment><USER29> My friend just left Google NYC to start his own company. He didn't give Google enough to give him an official counter offer -- he had already made up his mind -- but they did say that it would have been significant.

</comment><comment><USER8> Thanks for not using Techcrunch's title insinuating that there is a high- ranking Google mole within Twitter.

<comment><USER30> that's probably the only thing techcrunch is good at these days, coming up with these exaggerated titles. these days you can't help but roll your eyes on all the tabloid articles they post.</comment></comment>


Accuracy of Wrist-Worn Heart Rate Monitors - <AUTHOR> http://jamanetwork.com/journals/jamacardiology/article-abstract/2566167 <comment><USER2> Now if we had something like this for this accelerometer-based pedometers...</comment>


(404) npm goes down - <AUTHOR>

https://github.com/isaacs/npm/issues/2694 <comment><USER2> Here's a temporary solution if you're still facing problems:

Nexxy has changed the topic to: npm is down. use `npm install <module> \--registry <http://18.104.22.168:8000`> in the mean time. (thank mmalecki for the work-around)

</comment><comment><USER3> This is pretty bad. I'd expect them to do some local caching exactly for that reason. Second comment: "I am also having the same issue when trying to push to heroku."

<comment><USER4> Yeah, I had the same problem. Not being able to have the same level of control in Heroku was... unfortunate. Even after temporary local fixes were resolved I still couldn't push my app. Hopefully we can all take this as a learning experience and figure out how to utilize npm without keeping it in the critical path!

</comment></comment><comment><AUTHOR> looks like its not down but for some it requires a prefix of the package the registry

What npm is calling:

<https://registry.npmjs.org/-/express-3.0.0rc2.tgz>

what it requires to work:

<https://registry.npmjs.org/express/-/express-3.0.0rc2.tgz>

</comment><comment><USER2> Seems to be fixed, works for me now

<comment><AUTHOR> is still not working for me

<comment><USER2> It may be package specific. I think packages have to $ npm -force publish again to get working.</comment></comment></comment>


Apple logo and the golden ratio - <AUTHOR> http://gold3nratio.tumblr.com/image/6627609607

<comment><USER2> Amusing thing is the original was drawn by hand, so it likely didn't have all those ratios calculated accurately: [http://creativebits.org/interview/interview_rob_janoff_desig...](http://creativebits.org/interview/interview_rob_janoff_designer_apple_logo)</comment>


Great Entrepreneurs Believe in Karma - <AUTHOR> http://www.feld.com/wp/archives/2009/04/great-entrepreneurs-believe-in-karma.html

<comment><USER2> Ironic in light of [http://www.techcrunch.com/2009/03/22/the-nasty-exploding- ter...](http://www.techcrunch.com/2009/03/22/the-nasty-exploding-term-sheet/)

</comment><comment><USER3> _Whenever I help someone like the entrepreneur above, I'm paying others back for helping me._

A very American view of Karma - the endless paying back of an ongoing debt.

How about a view of Karma as a 'virtuous circle' instead?

</comment><comment><USER4> Really interesting in light of the 37Sgnals crap over the last few days. What kind of karma doesn't kicking a startup who made a mistake in the nuts generate?

<comment><USER5> That article made me smile.

I've had the same experience, where I've gotten some really great unbiased help and advice from people and I intend to pass it on in the future.

But putting that in perspective with the 37s and GS case; I'm not sure why they don't treat each other like they would like to be treated themselves.

</comment></comment><comment><USER6> I voted this up because of the title.</comment>