skysight-inc/HackerNews huggingface dataset:
I'm going to start a flame war here... I guess.

The thing about bottom up parser generators, is that they really aren't all that useful.

There's a dirty little secret in compiler development: most "real world" compilers use hand written top-down recursive decent parsers. They don't use Bison.

The classical argument in favor of using bottom up parsing is that it can recognize a larger class of grammars and is often more efficient than top down parsing.

This, however, ignores one huge point. Parser generators are leaky abstractions. They almost always suck at error recovery. This is particularly true for bottom up parsers because they don't have a lot of contextual information. Error recovery is extremely important for several reasons:

1. Parsers with bad error recovery give shitty error messages.

2. Things like intellisence, which always operate on syntactically incorrect code, won't work without good error recovery.

Some people have done research on automatically injecting error recovery into bottom-up parsers. These systems, however, are always based on heuristics, and supporting one set of scenarios well always leaves another set of scenarios not supported well. Those are exactly the kind of situations where you need humans to tune things.

The problem with parser generators is that their input languages are not turing complete (by obvious necessity). That means when the parser generator does something wrong, you can't always fix it. Most abstractions in computer science are not like this. They involve one turning complete programming language being compiled down into a lower level turning complete programming language. When abstractions leak, you can always code around the leakage.

But, with a parser generator, you can't do this. If you want to implement robust error recovery, then you have to add explicit productions to the grammar to handle them. That becomes extremely tedious extremely quickly.

That means to create a real parser, for use in interacting with humans, you need one of two things:

1. A customized parser generator, tuned for the exact parser you are generating.

2. A parser written by hand.

Item #1 isn't really practical. That leaves number 2 as the obvious best choice.

Writing bottom up parsers by hand is a giant PITA. That's why people invented parser generators, so they wouldn't have to spend an eternity hand crafting tables.

Writing top down parsers by hand, however, is really easy and intuitive. You also get full support of most code browsing tools and debuggers, so they are easy to change, even as the grammar gets large. They are also easy to read.

Finally, because they are written in a Turing complete programming language, you can easily (and with minimal code) inject what heuristics you need, in exactly the place where you need them.

Because of this, hand written recursive decent parsers are almost always the best engineering choice, despite all the other tradeoffs.

Despite all the proofs of the superiority of LR parsers over LL parsers, I would take a human, armed with a specific grammar and a for loop, over Bison any day.
Your personal computer is less likely to be compromised as part of a fishing expedition, like when the feds tried to get Google to turn over an entire week's worth of search history to help them defend of one of their "for the children" laws. I could easily see them demanding access to all Google Docs containing certain keywords.
I'd imagine that computing the cost of health care is an incredibly complex undertaking. Without being able to review the methodology used, this graph is next to useless. For example, here are just a few questions that come to mind (and I'm sure more would arise if the methodology was properly peer reviewed):

1. Are there no data points between the United States and Switzerland? Are there no data points above the United States and below Mexico? If there are, that would make the graph misleading and they have to specify this limitation if they're intellectually honest. If there aren't, they have to demonstrate that they've gone through the exhaustive list of countries and there are no other "interesting" data points.

2. Is the cost adjusted for cost of living at a given country? If not, that would make the graph extremely misleading. If yes, what adjustment strategy was used? Can we see the ratio between cost of health care and median yearly salary, for example?

3. What does "average life expectancy at birth mean"? Does it account for countries that have a significantly lower birth rate than the United States? I would guess not, which could significantly affect the perception of the numbers. How does one normalize for something like that?

4. How was the currency conversion rate computed? Currency prices fluctuate throughout the year, did they account for that? How much does that affect the numbers? Could be a lot, could be a little, but I need to know whether this was taken into account.

5. What does "universal health coverage" mean? Soviet Union had universal health coverage and no medication, surgery performed by under-qualified residents, and no post-surgery care, unless you know someone or bribe the doctor, of course.

6. Surely there are countries without universal health care other than the U.S. and Mexico - how do they stack up?

7. I'm willing to bet a country like Poland has a lot more homeless people that don't factor into the life expectancy numbers than the U.S. That begs a more general question of whether the same methodology was used for computing the cost or life expectancy for each country. If they simply took official numbers from each country, it's almost certain that they were computed differently. Was this accounted for? If not, I need to know. If yes, how were the numbers normalized?

One could probably come up with dozens of questions like these. Of course any analysis of a problem that complex can be called into question, that doesn't mean every analysis is useless. But before we can seriously discuss this graph, or base any policy decisions on it, they at least have to provide the methodology. It doesn't look like this graph is intellectually honest to me, and the burden of proof is on the author.
My vote: complete waste of time. I experimented very briefly with rentacoder before giving up on the idea of sites like this altogether. My experiences with services like this (and to a lesser extent craigslist) have been unpleasant to say the least. These days I only take on gigs that come to me through my network and even then I'm careful to vet potential clients before accepting a gig.
How do you vet your clients?
Nexus One rooted.
From his comment, I'd imagine he thinks that spreading lies and irrationality shouldn't qualify an entity as a charity.
Buy Mutant X: The Complete Set DVD [Season 1-3]. ON SALE
"Getting the best out of Freelancing Site" could be a decent selling book.
Headline should be "How to Run a Meeting Like Marissa Mayer"

I've heard that she is hated within the company for things like this. Maybe that's a minority view, but the article is still way too positive overall.
Assuming you're not a religious person, I don't really understand how a concept of answering for anything fits in your world view (except on an emotional level, that I can understand completely). It's all just atoms, right?

That aside, I haven't ever seen anything even resembling of well-constructed argument that religious people do less net good/more net harm to the world more than secular people.
not a bug, a feature
You mention specifically that it this is true for compilers. What about smaller applications. From my browsing of the FreeBSD tree most programs that have a syntax use yacc/lex to parse the input. Awk for example, among others.

As you are much more experienced in this area, any opinions?
> Java isn't slower than C in general.

Really? In general? That statements seams worse than the original headline. Is Java faster than C for anything?
A year without getting into a car
The same argument has been made about Linux in the past - and it has panned out; many individuals and companies pour resources into Linux development (Redhat, IBM, Oracle, etc), but yet it is still not a ubiquitous desktop OS.

I've given up on the belief that anything will succeed merely on the notion of being open.
"The C Programming Language", commonly referred to as just "K&R", is probably one of the best introductions to a programming language ever written. It's short, clear, and concise — even today, 31 years after its first publication, it should be your first stop: http://en.wikipedia.org/wiki/The_C_Programming_Language_(boo...

As previous commenters have said, don't worry about the details early on. Advanced pointer arithmetic tricks and the like are to C what zany metaprogramming tricks are to Ruby: dangerous, and almost always a bad idea — except in those few cases where they're exactly what you need. For your first pass, you can ignore anything that's not obvious. You probably won't need it anyway, and you'll pick the truly important things up with time…

Code on UNIX, preferably Linux, using CLang and a simple text editor to start. The Windows APIs are just plain confusing for beginners, and OS X adds some wrinkles to the compilation process that it's better not to worry about in the beginning. Linux isn't as austere as some of the BSDs, but that makes it an easier platform to learn on. Similarly, while GCC is more common than CLang, CLang has a bunch of features — actually useful error messages, for example — that make it much much easier to deal with. Fancy IDEs like XCode and Eclipse have their place, but are more complicated than they should be for "hello, world"-type exploration. All you really want is syntax highlighting…

Since it sounds like you're coming from Ruby, check out the FFI project: http://github.com/ffi/ffi FFI makes it reasonably easy to call C from Ruby, meaning you can build scaffolding in a language you're comfortable with while you focus on particular bits of C code. Similarly, it's not worth trying to learn the arcana of the C tool stack — make, autotools, etc — all at once, especially if you already know Rake.

Read other people's code. It's probably better to stick to smaller projects at first, especially reasonably modern ones which haven't gone too far off the deep end with the optimization. I don't have any great pointers here, unfortunately — the only thing that comes to mind is that (C) Python has some really nice, well-commented code and .txt files in its source tree, and that MRI Ruby is horrible. The libev API also strikes me as a good example at the moment — but that's probably at least partially because I've been staring at it so much recently…

Once you're feeling reasonably literate, the next step is to read some algorithms and data structures books. It's both a strength and a weakness of C that you essentially always end up implementing your own; even if you don't end up writing a lot of C code, getting a solid footing (or refresher course) in these will help make you a better programmer. After that, you can probably read code with the best of them. If you're still looking for more, I'd suggest maybe "UNIX Network Programming" by Stevens, Fenner, and Rudoff (a good introduction to the sockets API); or "Modern Operating Systems" by Tanenbaum … really, it just depends on what you're interested in.

-sq
That is not the only reason she is hated, but yes, some of these things are on the list. In her typical fashion, they are stated in a positive manner when really some of them have extremely negative consequences. But I guess these are the perks of being in the first fifty and having the king's ear.

1. Set a firm agenda.

It also helps to have and frequently exercise unilateral veto or green light power. It's a lot easier to hold meetings in which you don't have to build consensus or even explain your decisions to the people whose year's work you are killing after just having heard of it half an hour before.

2. Assign a note taker.

Sucks to be the engineer who gets this task. Maybe my brain needs a second channel where I can actually think about what's happening and one to take the notes with. As it is, when I get to be the note taker I'm reduced to a speech-to-text machine with no agency in the room.

3. Carve out micro-meetings.

Once again, absolute power of the pen makes this a bit easier.

4. Hold office hours.

Nothing to complain about this one. Damn good idea. Wish I had the political capital to pull it off myself but it's hard to get people to buy into that when you are an IC. My workaround is to disappear from my desk a couple hours of each week to put my head down. Not as effective as "You can only talk to me between three and five on Wednesday, and by the way sign up two weeks in advance before all the slots are booked out," but we work with what we've got.

5. Discourage politics, use data.

That is, when it's beneficial to the point of view you already hold or when you don't care and just want to make a safe decision.

6. Stick to the clock.

Whatever. OK, I guess.

I'd also like to point out that none of these things happen in the vast majority of the meetings I attend. Normally it's agenda-free and the most senior person in charge wastes everyone's time by interrogating the tech lead about things that senior person should have read in the design document that was sent out the day before, and that besides that are higher resolution than the senior person rightly needs to know about, while everyone else sits around and checks email. Like meetings at any company.
Can music predict the stock market?
Airport Security Is a Computer Problem
From a buyer's point of view: odesk.com and elance.com are pretty good. All the others - not so much.

As a service provider - you will always get paid a bit less though - because of the real time competitive bids. When 15 coders bid for the same project, no matter how skilled you are - you will have to make competitively priced bids to win the projects.
Pimp my programming language
I've used it for small web coding projects and had decent luck.

I always lay out the items which need to be completed with excessive specificity. That's the stage where I've seen a lot of people get let down, disparity in the expectations due to assumptions from each party involved. Never had any issues with payment, either.

If you're very plain and up front things will work out. Make sure you ask any questions so everybody understands what they need and what they're getting prior to any work or payment being completed.
because if you already have to write javascript for the datepicker, why figure out if the browser supports html5? why not use the datapicker you just wrote (using yui or jqueryui or whatever)?

to do otherwise just adds more work, not only for detecting the browser, but for making sure the page layout and so on works in both versions.
Good point, thanks, I was thinking I should have addressed that. The thing was that no one was digging ditches. Yes, given a choice, it would be more efficient to use unskilled labour than a surgeon... but it would be better to have a surgeon doing it than having no one doing it.

In practice, I imagine his role as an advocate and organizer: a kind of charity-entrepreneur, and maybe leading by example, gandhi-style, rather than being an ordinary ditch digger. "This is so important, that I can save more lives by doing it instead of doing surgery". Of course, there are many problems with making infrastructure changes, cultural, practical, political; and maybe it needs special talents, skills, values and especially personality that even a highly intelligent, competent and committed surgeon may lack. But if you believe that's the best way to improve health, and you are committed to improving health, then...
Touche. I believe the Facebook tell-all book "The Accidental Billionaires" opens with this quote.
why do people expect japan to rebound at all? with a severely aging population that is highly xenophobic compounded by deflation creating at best a flat to negative domestic consumption. This results in any economic growth being highly export dependent and has been for the last 10+ years.

so.. a double blow, the great recession and the new decade of retirement, its a slow fade to #4 or #5 in world GDP.
Why is this pointing to the Seattle Times instead of the New York Times? The NYT originally published it and has a full photo essay to accompany the story.

http://www.nytimes.com/2010/01/02/business/global/02capsule....
What does that do to the pancakes?
Really, why was I down voted? I'm not sure what was wrong with the comment. I think anyone would agree with the idea of tort reform, just like anyone would agree with the idea of health care reform. But even if you don't, I thought that with Hacker news, you only down vote people when they aren't insightful or off-topic. So, a differing opinion also accounts for down voting now? Like on Digg?
Programming in a Vacuum
For Some of Japan’s Jobless, Homes Just 5 Feet Wide
> 2. Allow any doctor in a country with reasonably competent medical standards to practice in the United States.

Not even that. Canada gets many South African doctors (most of which are fairly competent). In addition to this, they continually monitor doctors. So, if an incompetent doctor slips through, he is quickly caught and his license is revoked.
It's a fascinating idea, especially what would their language (syntax) be like if they didn't have the concepts (semantics). Or would it turn out that they do have enough in the way of concepts, and have only lacked the language to express it? Or does syntax play a greater role in intelligence than we'd thought - not fully whorf-sapir, but perhaps there is some contribution, in the way that going from regular to context-free languages makes a difference? (personally, I think most of the power of our language comes from a huge vocabulary and combining it in regular ways; the CFG aspect doesn't seem so to be so profound in practice to me)
Martial Arts for Geeks?
I've heard a lot of geeks say they do martial arts. I hate going to the gym, and am looking for an alternative to stay in shape.
Martial arts sounds interesting, but... doesn't that hurt? I'm a little weak geek, and would like not to get things broken, or having to limp around. Is there anyone with the same "background" here that does martial arts? How much time a week should I expect to put?

Thanks!
The clothes don't make the man (boy)
The user cwan nailed the general failures of Japan's economic policy in the 90s, although the root of the problems extends farther back in time than even the Economist article covers.

Back in the 70s, Japan's rise as a world economic power was fueled by government loans to private industry, allowing banks to fund abnormally large investments in industries, specifically manufacturing and technology, which helped support the rise of the global Japanese brands (Honda, Sony, etc).

These same funds also helped inflate the massive real estate bubble the article briefly covers by selling the concept of the limited real estate space in Japan. What investors in Japanese real estate failed to realize is that even though there is a limited space in Japan, there is an unlimited price that a given piece of land may be valued at but a limited price that it can be intrinsically worth compared to the value of all other assets (hence the overinflated valuations of the properties).

For a long time (70s and 80s), Japanese companies made solid progress in commanding global sectors, and their auto companies still do. However, the loans became so large and the earnings generated by the firms eventually declined to levels where the loan payments could not be made. The subsequent bank write-offs on all assets were the cause and/or effect (really a self-perpetuating vicious cycle).

I cover these to give a positive spin on the United States situation. While the government has made a number of mistakes in regulating the banking industry and partially inflating the housing sector, it has not tried to directly inflate the economy to the scale the Japanese government did in the 70s. The United States government is propping up some American industries, but again, not to the extent of the Japanese government in the 90s. If that were the case, they absolutely would not have let Lehman Brothers fail. The government is in a tough position, trying to prevent political and economic chaos while allowing markets to reach their own equilibriums.

For anyone who fears the China may be catching the United States economy, there is a good amount of evidence that China may be suffering the same syndrome Japan had in the 70s (building its economy based on government money). China will likely deal with the problem more efficiently once a bust occurs, but it does mean that China could be less of a threat than many suspect, assuming the United States is able to innovate at a reasonable rate.

Here is a decent article/example of what I am talking about with China: http://www.bloggingstocks.com/2009/09/09/petrochinas-sugar-d...
It completely depends. Both are silly generalizations.

Yes Java can be faster than C in some situations.

Can C ever be faster than assembly? Well, in theory no. But in practice, sometimes.

Depends if you're a master assembly programmer who hand optimizes everything.
Mint.com pitch
Keynes would agree with you...in the General Theory, his argument was that the "natural" state of the economy was a liquidity trap. Rising productivity results in an increase in aggregate supply, which results in persistent deflation, which encourages people to hold money instead of investing it, which results in a cap on that productivity.

IIRC, he even suggested that Europe's long period of stagnation during the Dark Ages was because real interest rates were so high that rational entrepreneurs would never invest in new technology, because there was no conceivable way that they could generate a positive return on capital. And that the pyramids were ancient Egypt's solution to the problem of Keynesian stimulus (i.e. nobody was investing, so they built the pyramids to forcibly confiscate money through taxes and then distribute it to workers who would actually spend it).

It makes me wonder what we're in for over the next 10 years. I don't really believe the "permanently stuck in a deflationary trap" theory - there's too much evidence against it. But I think the normal way countries get out of it is through war, which isn't terribly rosy either. In addition to the direct Keynesian stimulus, it also encourages rapid technological development, which opens up new markets that then become fertile ground for investment after the war.
You should be weary of using Lex for unicode, because the tables can get large.

As far as Bison goes, I guess that's up to you. My preference is against it, mainly because I don't think it buys you much (if the grammar is small, the code for the parser should be small to).

The biggest driver should be user experience. If you care a lot about how errors are reported (i.e. you want to avoid cascading errors, while trying to report as many errors as possible up front) , then I say you should definitely not use bison.

If you don't care about error reporting much, then its really just based on your personal preference.