lisa_henderson

About this:

"Though a jury is a good idea and the best we've got, the process they run through seems ripe for reform."

How do you justify the statement that a jury is the best idea that we have? Germany has the concept of Schöffe, and some believe this offers results that stick closer to the law than the jury system:

http://www.britannica.com/topic/Schoffe

While any government of mortal human flesh must inevitably have some flaws, the jury system seems especially bad at overcoming popular prejudice. In the USA, "a jury of one's peers" has often meant a mostly white (or all white) jury judging a black person, a circumstance that has given the USA many hundreds of famous miscarriages of justice.

The system that grew out of English Common Law, and which dominates England, Canada, the USA, Australia and New Zealand, is not the only system known to liberal Western societies. The English system is unique in the authority it gives to juries. Most of the Continental judicial systems either lack juries or have juries whose goal is constrained relative to the English system.

A review of the legal traditions in liberal Western nations reveals a lot of good ideas, many of which are probably superior to the jury system.

That would be normal in any big city. For over a century the general rule was "Move to the suburbs if you want to buy a house. If you stay in a city then you rent." Things have only changed slowly, since the 60s, with the rise of condos, that has made ownership slightly more common in the cities.

This bit raises the question, is #1 being caused by #2 and #3?

--------------------------------------------

The problems that we have hit with using Typed Closure are

1.) slower iteration time when programming,

2.) core.typed not supporting the entire Clojure programming language

3.) using third-party libraries that have not been annotated with core.typed annotations

--------------------------------------------

If #1 is caused by #2 and #3 then presumably #1 will get better with time. But if #1 is caused only by typing itself, then it sounds like, for them, using types was a bit of premature optimization.

It does raise the question, is it possible to create a type system that does not slow a project down?

About this:

"but there's lots of people who live < 10 miles away from Google who'd be willing to do it if there was better infrastructure"

Then the headline should be "Google wants to make biking easier in Silicon Valley". The comparison to Copenhagen simply doesn't make sense. Riding a bicycle to work is an activity that is practical in denser areas, not in historically suburban valley.

You should include both of them:

https://en.wikipedia.org/wiki/Ariel_Durant

And yet, this is the exception that probes the rule. The above quote has an element of humor in it, and it is basically saying "No modern marriage would allow this, as no modern spouse allow themselves to be ignored for so long." But Will and Ariel Durant did not have a modern marriage. Such a marriage is now illegal everywhere. Will Durant would now get 10 years in jail for announcing his feelings.

A commit message should answer the question "why?".

In the article they ask "Which would you rather read?"

I would prefer to read the first commit message they offer as an example:

"Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle downstream effects, breaking unrelated tests. The test method is still useful, but should only be run on a manual basis to ensure CGLIB is not prematurely classloaded, and should not be run as part of the automated build."

That is informative and gives me the information that I need. It answers the question "why?". And yet, this commit message is held up for criticism. And then, this is given as a recent example:

"Rework @PropertySource early parsing logic"

I have no idea what happened in that commit. And this commit does not answer the question of "why?".

I disagree with this entire article. The examples of "bad" commits are the one's that I would want my co-workers to write. The example of "good" commits are the kind that would make me angry with my co-workers.

Verbose commit messages are not useful because they are verbose, but a commit message should answer the question "why". Commit messages that answer the question "why" tend to be a bit longer than commit messages that fail to answer that question. I would much rather read a verbose message that answers the question of "why?" than I would read a short message that fails to answer that question.

I wonder why this was downvoted? I'm stating what should be obvious to everyone. As the human habitation moves deeper into the woods, there is an increase in the political motivation to engage in "assiduous firefighting".

This article has an innocence that seems almost willfully blind. They write:

"But assiduous firefighting is also to blame."

They don't spend much time talking about the most obvious force that drives the "assiduous firefighting". The expansion of the suburbs have pushed human habitation out into what used to be the middle of a forest. Also, the increased popularity of what is sometimes referred to as "country living" but which is really a form of low density suburban living, has added to the trend.

The point is, areas that used to be free of humans now have a bunch of $1.2 million dollar homes. And thus you have an affluent demographic that is pushing hard for "assiduous firefighting". And that trend will continue so long as the suburbs continue to expand, which will likely be a long time.

The article has a tone that suggests policy makers are simply making an mistake by engaging in "assiduous firefighting". Overlooking the political forces that drive this make it difficult to understand why it is difficult to stop.

I also had Lyme and I was also given metronidazole, in combination with other antibiotics. The theory for giving it was that Lyme, during its life cycle, has several forms, including a form that is a bit spore like (that is an informal and non-technical description of what I've read) and normal antibiotics are not effective against the spore form. The theory was that if you had Lyme that recurred often, as I did, it was because some of the Lyme was in a form that could not be reached by stuff such as Biaxin. Therefore, taking a combination of drugs, including metronidazole, was suppose to be more effective than taking any one antibiotic alone. For me, metronidazole did not work, or at least, it did not achieve the goal. It was wonderful for weight loss, but it did not help me beat Lyme. For me, I got over Lyme during an odd episode where I combined Biaxin and fasting (going a week without food, a week when I only had water and high doses of oral Biaxin).

Fascinating that even here on Hacker News, where we can presume the audience is well-informed about tech matters, the comments on this post show a large amount of confusion about the definition of "RESTful". I see some comments raise the issue of XML versus JSON, as if the encoding format impacts on whether something is RESTful. I see others raising the issue of HATEOAS, with some comments suggesting that RESTful is HATEOAS, and others suggesting that RESTful is a different approach from HATEOAS.

A term that lacks any agreed upon meaning is of no value. But I wonder why the meaning has become so blurry?

I was under the impression that the bible on this subject was the 2007 book by Leonard Richardson, Sam Ruby (and a nice forward by David Heinemeier Hansson):

RESTful Web Services

http://www.amazon.com/RESTful-Web-Services-Leonard-Richardso...

However, reading the comments on this page, I have the impression that many people here have never heard of that book.

I just started at a new job, at a new startup.

During the my first job interview with them, they asked, "Do you know how to work with a RESTful interface?" I said yes, and I told them to look at my Github account for examples.

During my second job interview with them, they asked "What do you consider when you are designing a RESTful interface?" I quoted a bit from the book that Sam Ruby and Leonard Richardson wrote, back in 2007, and which I've read cover to cover. Among other things, I said the overall goal should be to work with HTTP, not against it. Then their lead programmer tried to ask me what he apparently thought was a "trick" question. (He was quitting the startup to go back to school, and I was being hired to replace him.) He asked, if, for a given task, HTTP was too verbose a protocol, then what else might I use for a RESTful interface. I suppose that should have been my first warning. I wasn't sure what they were looking for, but I thought maybe they wanted me to say WebSockets, or perhaps they wanted me to push back against the question and ask why HTTP was too verbose, or they wanted me to suggest the use of TCP in an ad-hoc style that mimicked HTTP. I explored all those possible answers as I spoke with them.

Then I was hired and I started the job. Their system is not RESTful at all. The only HTTP verb they use is POST. They use it for everything, and they put all their data in the body of the POST. Their system is pure RPC, with a style influenced by SOAP.

The people I'm working with are in their early to mid 20s. I'm not sure if age is a factor, since I've seen the same mistake made by programmers in their 50s. But, for sure, there are some programmers who do not seem to know the difference between RPC and RESTful.

Of course, on a personal level, none of that really matters. I really like this place that I'm now working, and I'm happy to work with their RPC style. I have, however, insisted that we use correct terminology, just for the sake of clarity.

This is ridiculous:

@carbocation: "If you are interested in a physician's help but do not want to take a specific medication or class of medications, things will get a bit more complex"

You don't understand the pressure the doctors are under to prescribe these things. A few years ago I was bit by a tick and a few months later I developed severe problems because of that tick bite. One of the problems was that my heart would sometimes race. The doctor put me on antibiotics to deal with the bacteria from the tick bite, but the doctor said I also had to take Paxil. I asked, why would I need to take Paxil to deal with a tick bite? She said the racing heart indicated anxiety, which needed to be treated. I said, if the bacteria causes anxiety, won't that antibiotics resolve that? She said yes, but in the short term I needed to take Paxil. I asked, if the problem is assumed to be resolving in the short term, and the episodes rare, isn't this a classic use-case for something like Atavan or Klonopin? We discussed it for a long time, and we went round and round in circles, but in the end she made clear that her decision in this matter was final: my choices consisted of taking Paxil or finding another doctor. Since this woman was a well known specialist in treating the kinds of bacteria that one can pick up from tick bites, I decided to take the Paxil. But it struck me as absurd then, and now, that I had to take Paxil to deal with a tick bite.

david gerard, if I could upvote your comment a thousand times, I would. Especially this:

"Who thought "Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean" was a good idea WHEN IT'S A DAMNABLE LIE?"

I use git because everyone uses git, but I wish the tech industry had consolidated its use around a version control system with an easier-to-understand API. Especially when it comes to "undo". For desktop software, I can just hit Command-z, but git has a complicated syntax, and it is course grained -- per commit rather than per file, and then there is the issue of whether the files have been pushed to the repo yet, or not. To me, the whole point of version control is to have infinite undo, and a version control system that makes that difficult is a bad version control system.

But the worst thing is probably merges -- I merge in a whole other branch, and want to push the changes from that other branch to the repo, as part of my current branch, but git says that everything is up to date and there is nothing to push -- what the hell is that?

Fascinating, and very similar to my own family. This is especially true:

"When faced with evidence of their children's true feelings about unwanted contact, parents minimize ("What have we been doing to him? Nothing but telling him we love him!"), deny ("She's saying that because her abusive husband ordered her to"), demand explanations ("Why should she be afraid of me? I'm a weak little old woman who wouldn't hurt a fly!"), assert that they are still doing the right thing ("How can this estrangement end if we don't talk about it?"), and dismiss their children's emotions. The dismissal is the hardest part to watch. The common attitude is that estranged adult children shouldn't feel the way they do, so their nonconforming emotions can be ignored. Even when estranged parents get direct, unvarnished information about how they affect their children, they refuse to believe anything that goes against their idea of how the relationship should be."

Thank you for saying that. The last 15 years have seen tremendous heat and noise exhausted in fantastical debates the end result of which brings no obvious improvement. If we were honest, we would say something humble, such as "Sir Tim Berners-Lee is a great genius, and we are all grateful for what he gave us in 1989, however, since that time, we have learned many things, and the technologies proposed then did not give us what we actually need. HTML strains to fulfill two discordant goals, one is to give us structured documents, and the other is to give us a GUI for TCP/IP. But we now realize these two goals would be better served by two separate technologies, and HTML should be retired."

Is this a typo?

"at least they understood that threat of death is worse than threat of injury"

Surely you meant to write the opposite? As we've all been told, over and over again, at least since it became clear that President Bush was encouraging torture, is the old slogan "death is what you wish for when you are being tortured."

Personally, given a choice between a quick, painless death and some of the worst kinds of torture, I would always chose death. Rather death than, say, being tied tightly in a chair while someone takes some nails and a hammer and hammers the nails through my hand, or being bound so I can not move and then having rats allowed to eat my face and eyeballs.

I love this story. It offers an important reminder about how our industry really works.

Whenever a practice becomes established as a "best practice", such as automated testing, then the next question that arises is "Why isn't everyone doing this to the max?" And folks that don't follow best practice generally feel guilty and keep quiet. But those who follow fashions in tech tend to underestimate the opportunity costs of doing so.

This is the moral of the above story, and it is a good one:

"Hopefully you are horrified by all things we didn't do that are now considered best practices. No reproducible builds, lack of automated testing, creating and then repeatedly sidestepping technical debt. For a long time, that is how I told these stories: as horror stories that came complete with hand gesticulations to emphasize the "can you believe I had to do that?" nature of it all. Here's the thing though: we were making money. We were growing and supporting ourselves."

I spent this winter working for a startup that had the opposite problem of most startups. The CTO was a serious Pythonista, and he wanted to ensure that all the code was written was of high quality. He wanted to avoid the build up of technical debt. There were 9 programmers on the team, using Python on the backend and AngularJS on the frontend. And he felt they could invent a new way forward, in terms of combining Python and Angular. And so the team was reinventing the whole Python stack: they had their own serialization libraries, their own database libraries, their own web server, their own authentication system. Adding each new feature lead to very long meetings in which people were encouraged to be thoughtful -- everyone was suppose to think about the long term consequences of whatever design was chosen. In some ways, it was a careful style, but it had a cost: the 9 developers spent more than 50% of their time on infrastructure questions that had already been solved elsewhere. In terms of meeting the real needs of this small startup, the startup might has well have had a team of 4 developers -- the money paid to 5 of the developers was, in a sense, an act of charity being offered to the Python community.

We've all ready endless stories about startups that cut corners, ran up technical debt, and eventually succeeded. We read much less often about startups that doing everything perfectly and then become successful. And that suggests that, for startups, cutting corners is the more adaptive path.

The rules about titles on Hacker News are both stupidly strict and then erratically enforced: a bad combination. dang said he would bring more transparency to this, and he has done so where he comments, but I assume, his time being finite, he often has to focus on other things, which leads to the erratic nature of the enforcement. I do wish they would allow more freedom about titles and also about article submissions. I'd also love to see more transparency about why certain articles are forbidden, such as this one: http://gawker.com/why-weve-decided-to-organize-1698246231

I bike to work in New York, and I've biked around Berlin, and I would say New York still has a way to go before it catches up with Berlin.

The problem that New York faces is that it is embedded in USA society, so it has to face some issues that are not about bikes, but effect bikes. An example would be the reasons people use bike helmets. No one uses bike helmets in Berlin, because Berlin is safe for bicycles, and that is partly due to the respect that cars and trucks show to bikers. In the USA, car culture is stronger, and car drivers are much more aggressive. I've gotten into the equivalent of tug-of-war situations with taxis, trying to exercise my right to turn, when they want to turn in the opposite direction: the taxi drivers are willing to use the vast bulk of their car in a threatening manner. You never see that in Berlin. In New York City, one is justified wearing a helment, and one would be justified wearing elbow and knee pads (but I never had). It's an aggressive environment.

Also, in New York, the roads are often chaotic. In Berlin, I only saw chaos around construction sites, otherwise the roads were safe and orderly.

Also, I could rent a bicycle in Berlin, very cheaply, and then keep it for days. There is nothing exactly so convenient in New York.

All the same, I am pleased that the situation is getting better in New York.

Seems like his story can be thought of as a data point for those who argue that info-grazing doesn't benefit the grazer as much as the grazer might like to think. Here is a fellow who oversaw MTV Online during the time it failed to capture the youth demographic online, and also he oversaw MySpace during its collapse. What exactly is the point of being well-informed if being well-informed doesn't give you the information you need to succeed?

Consider:

"Later, he was President of MySpace at a time when MySpace was still a big deal, though in rapid decline. Yet through all this, Jason always found time to send out a daily list of articles for people in the media and technology industries."

and:

"At Viacom, Jason rose through the ranks. By 2005, he was running digital media globally for MTV Networks."

This next bit seems to suggest that he was unable to succeed due to political factors:

"Since Jason was the “Internet Guy” at a non-Internet company, his opinion wasn’t always given due attention."

He attempted to combat the political factors by sending out his newsletter. However, the article doesn't suggest any breakthroughs at Viacom that derived from the articles that he sent people.

Some political situations are hopeless. Some can be fixed by building an internal coalition. Can some be fixed by sharing a bunch of articles from online? Are there success stories for this technique?

Let's be realistic: there are many companies that won't hire you after this. The question is, are those the companies that you want to work for? It's a tough choice, of course.

You mention that the company you worked at is popular here on Hacker News. So let's assume we are talking about Apple or Google or perhaps AirBnB. So from now on, when people look up your name, they will see something like "Testified against Apple".

A lot of companies will quietly remove you from consideration, if they see that you have testified. And, sad to say, this might exclude you from a lot of the better paying jobs in the industry.

All the same, you have to ask yourself, how will you feel about yourself if you don't testify? What kind of world do you want to live in? What sort of tech industry do you want to live in?

Also by Clay Shirky, and very much worth reading:

Healthcare.gov and the Gulf Between Planning and Reality

https://news.ycombinator.com/item?id=6770039

You misread the sentence. The comparison is being made to the Mesozoic. That is, the Mesozoic was much hotter than the Cretaceous. I can not imagine what you mean when you write "Global temperatures don't correlate ... with the amount of carbon sequestered in fossil fuels." I never suggested any such thing. But we do know that carbon can increase the temperature, and if we dig up an amount of carbon that was buried over 500 million years and we burn it all during a 200 or 300 year time span, then presumably we end up with more carbon in the air, at one time, than ever occurred before, and therefore we should expect the temperature to spike to a level never seen before.

The title says "All Our Fossil Fuels" but they really mean something like "all the fossil fuels we are likely to dig up given reasonable economic assumptions." If they really meant "all" the fossil fuel, the results would be worse than they suggest.

If you consider this:

"The climate of the Cretaceous is less certain and more widely disputed. Average temperatures were higher than today by about 18 degrees F (10 degrees C)."

http://what-when-how.com/global-warming/mesozoic-era-global-...

Then this seems a bit odd:

"an astonishing 16.2 degrees"

That sounds accurate if they mean Celsius but this is the New York Times, which I believe uses Fahrenheit as a matter of style, and they write: "Scientists predict global disaster at 3.6 degrees Fahrenheit over pre-industrial temperatures; there is enough fossil fuel extracted and within reach to raise temperatures 16.2 degrees" which confirms the use of Fahrenheit.

It's frightening to consider the impact it would have if we really did dig up all the fossil fuel, including the stuff that we probably won't be able to reach. It's worth thinking about, since technological breakthroughs now allow us to reach a great deal of fossil fuel that was considered uneconomic 30 years ago and, likewise, 30 years from now we might be able to reach fossil fuel that we now consider unreachable.

Assuming large concentrations of life, allowing the formation of fossil fuels, starts with the Cambrian, or a bit after, we can say that "all our fossil fuels" refers to the deposits that built up over the course of 500 million years. If we dug all of that up and burned all of it, then we should arrive at a temperature that is a bit hotter than anything that ever occurred before. If the Mesozoic saw average temperatures that were 10 degrees Celsius higher than today, then something like 16 degrees Celsius would be a reasonable guess. Or higher.

"they were correct across the board"

That's impossible. The "Anti-Federalists" were a diverse set of groups with no unifying themes other than opposition to the newly proposed Constitution. Southern racists and Northern working class movements made anti-federalist arguments for wildly different reasons. It's impossible for anti-federalists to be "correct across the board" because some of the arguments they made were contradictory.

More so, it is trivially easy to find anti-federaist arguments that turned out to be wrong. Several people who identified as anti-federalist predicted that the new constitution would lead to tyranny, and yet, 227 years later, the government retains most of the nominal forms of a liberal polity: a mostly independent judiciary, freedom of media, public criticism, habeus corpus in all but the most extreme cases, etc.

At one point I tried to think of every musician that I could. I listed 923 musicians. I gave up, but I realized I had not scratched the surface: rock music, pop songs, American songs, African songs, French songs, classical music, etc. I'd guess if I tried for a few days I'd come up with 3,000 names.

Then I started thinking of all the people I knew who had something to do with computer programming. I allowed myself nicknames like "Matz" because I can not remember Yukihiro Matsumoto. I know a lot of the famous ones: Guy Steele, McCarthy, Edsger Dijkstra, Rich Hickey, Paul Graham, etc. I also thought about all the tech bloggers I read, which is a huge number. I've got over 300 tech blogs in my RSS feed reader.

Again, I got to almost 1,000 and quit, but I realized I knew a lot more, easily 2,000, maybe even 3,000.

Then I did the same with favorite writers, and I got 540 names without trying too hard.

Then I started with actors and actresses and directors. I got over 400 without too much effort. I think if I devoted a few hours to it, I would get more than 1,000, maybe 1,500, or even 2,000.

Then I started listing people I've known during my life. I allowed myself to describe people who I knew 20 years ago, who I remember clearly though I don't always remember their names. I got over 2,000 during about 90 minutes of trying. I think if I devoted a whole day to it, I might be able to double that number.

Then I allowed myself to write down every fictional character I knew, from Hamlet to Bilbo Baggins to Wolverine. I got well over 2,000 names with maybe an hour's effort.

What I learned from this experiment is that I must know of well over 20,000 people. I might know 50,000 people, counting both fictional and non-fictional people.

That, to me, says a lot about what humans do with the extra brain matter they have, relative to apes.

The pain I've felt with Angular has been less about Angular itself and more about the way it integrates with the backend frameworks I've seen it used with. If the backend has a clean RESTful API, then Angular is not so painful. If the backend has a complicated structure, then I find myself wasting epic amounts of time trying to find templates, paths, etc.

Angular will make a lot of calls to the backend, but in general you can not look at your Angular code and figure out where all the calls are going to the backend. Complex URLs are often assembled from diverse variables that are stored in varied locations. You can not grep for an URL because it does not exist as a string. There is no equivalent to the "rake routes" command -- no way to find out what routes Angular might use. I found myself opening the dev console on FireFox and watching what Ajax commands were issued while the pages loaded and operated -- which is a fine way to track down a call that is working, but if a call isn't working, then it won't show up in the dev console, and you are left trying to track it down.

There might be some structure or conventions that would allow us to find the problem when facing a bug in our Angular code, but so far we have not found it.

Agree strongly with this: "Does anyone seriously think that was anything other than hitting on Pao?"

Any man who is beyond college age, and who sincerely does not realize the meaning of handing out gifts and asking women out to dinner, is an idiot and should be removed from any position of authority. Emphasis on "sincerely" -- Randy Komisar is not that stupid, and his denials are hardly sincere.

The line "his wife bought the gift for her" has become something of a cliche which married couples use when the husband has been caught flirting but the wife is not yet ready to end the marriage.

Gifts given in public, for work well done, are always welcome, but a pattern of private gifts and requests for dinner are universally understood to be requests to initiate a sexual relationship.

One last word about "sincerely" -- there are some men who sincerely are that stupid. I have known at least 2. They somehow reach middle age and it does not occur to them that the gifts they are giving to an attractive young woman are being interpreted as sexual overtures. As Schiller said, "Against stupidity, the gods themselves struggle in vain." There is no cure for such men, but they need to be kept out of positions of power.

Scala has always been multi-paradigm -- that can be a strength or a weakness. Martin Odersky seems brilliant, and I've enjoyed watching some of the talks he's given, but he also seems to define words in a way that goes against the way I use those same words. For instance, he seems to conflate "module" and "object" to the point that any language with "modules" is also an object-oriented language, which is odd, since that would make Haskell and Erland object-oriented. I'm thinking of what he wrote here:

"Objects done well provide a lightweight module system (in the sense of ML). The requirement for a good module system is something that's often overlooked when all you do is a simple application, but its lack becomes painfully apparent for large systems and systems that are maintained over time. You can go the SML route and provide a module system and a functional core language. But then there's the pressure that you want to generalize your modules to be more flexible, which means you want them to become recursive and first-class. If you do that, you end up with a de-facto object system in addition to your core language of algebraic data types and functions. Scala's approach of unifying modules and objects is more parsimonious: The same constructs define the core language and the module language. So Scala is simpler, in the sense that fewer concepts are needed to describe the total feature set."

Others have already commented on this, and I have nothing more to add, but I do find myself doubtful about whether the "Scala is simpler" is justified. Scala has always been multi-paradigm, so I don't think of it as simple -- and, again, that can be a strength or a weakness. I'm reflecting on what was written here: http://scala-programming-language.1934581.n4.nabble.com/OOP-...

I wonder why this was downvoted? I think the point is obvious: if you suspect that founders, employees or investors regard their company's IPO as any kind of finish line, then you should run away from that company. Here on Hacker News there have been many stories about companies doing badly once founders cash out. And we have read many stories about the negative signal that it sends. I thought this was common sense, and so I didn't see a need to post any links, but it is trivially easy to find articles on this subject:

If Groupon were such a great business, why have the founders cashed out in each of the investment rounds?

http://www.quora.com/If-Groupon-were-such-a-great-business-w...

"But even beyond the lockup, a founder selling a significant chunk of equity can send a negative signal to the market and erode confidence."

http://www.rudebaguette.com/2012/05/22/going-public-its-comp...

"Zynga’s Mark Pincus is promising in an open letter to potential shareholders that his company will be a 'meritocracy'. Except that in his meritocracy, Pincus has created a class of stock just for himself. He’ll have 70 votes for every supershare of Zynga he owns."

http://www.thedailybeast.com/articles/2011/12/14/zynga-s-ipo...

Do a search on Google and you'll see a thousand articles like this, all with the same theme: when insiders sell, you should run.