copper

Speaking from painful experience: my problem with redoing the calculation is that whatever I did tends to stick in memory, with the inevitable result that I do exactly the same mistake again.

Check calculations like this are much easier to do mentally, and provide a rough measure of confidence in the rightness of the result.

FWIW, with C++, the advantages of linking to tcmalloc make it the default for any code that I write that isn't intended to run as a daemon -- and even there, unless I hit tcmalloc's limit of not releasing memory back, it's still a viable choice.

To offer a contrasting opinion: this is very similar to the kind of whining I used to hear from middle-management about employees who hopped from one job to another during the boom days.

I thought the author was trying to get at the old Babbage quote on confusion of ideas.

FWIW, I use git-svn to handle complex merges in svn because git has a better merge algorithm. While this particular situation doesn't affect that use case - I think it could, but it should be rare with (svn) branch discipline - the fact that it might is something to keep in mind.

If you haven't used this already,

    youtube-dl -U

In the off-chance that you've not seen this talk by Tim Sweeney: http://lambda-the-ultimate.org/node/1277

> "the best student I ever taught algorithms to is female."

Steve Skiena calling someone his best student is a strong statement - any idea who this is?

Norway does that too:

http://skattelister.no/skatt/profil/liv-johanne-ullmann-3417...

Edit: Heh, obviously, this has done the rounds on HN while I was asleep.

That's how RSU's work, though. AFAIK. grellas is right that there's a difference between restricted stock and restricted stock units (which in practise have a tiny, fractional price of the actual market value).

> Is there a cultural issue here?

There is, but it's probably the same point that's been made over and over in the submission of the WSJ article to HN.

FWIW, what Sridhar says in his article is exactly what zwischenzug said too :)

Here you go: http://www.stat.columbia.edu/~cook/movabletype/archives/2010...

One of the comments on the original paper (the pubmed link that teraflop cites) did point out that it was "just" the trapezoidal rule, FWIW, so the only people one may want to find fault with were the who stopped at his paper and decided to cite it, rather than dig further.

To nitpick, the discpline of physics covers everything - or it damn well ought to :) While it seems obvious after reading the article that solving the rendering equation is indeed a promising way to solve the Pioneer anomaly, I'm sure that I wouldn't have come up with the idea.

There's also the example is about how one medical researcher apparently rediscovered the trapezoidal rule, and managed to get a lot of citations to his discovery.

> Of course, other groups will want to confirm these results and a team at the Jet Propulsion Laboratory in Pasadena, which has gathered the data on the probes, is currently studying its own computer model of the thermal budgets.

Here's to hoping that the numbers match. Phong shading to calculate numerically the effects of a what is almost a solar sail to decelerate Pioneer - now that's cool science!

> I chose primes near the golden ratio to maximize the appearance of randomness.

Anybody know what this appearance of randomness is?

Duh. missed that one.

Yes, I remember that one: http://www.physorg.com/news/2011-02-chernobyl-birds-smaller-...

Rereading it, it seems that the effects seen on the birds are seen in humans too, but at higher contamination levels.

As someone who saw the fun Paypal had with the Indian government, I suspect the key word in that above quote is "eligible"

> JPEG still does not though.

You're right in practise (AFAIK, libjpeg still doesn't support this mode), but see http://en.wikipedia.org/wiki/Lossless_JPEG

Dybvig's expository style reminds me very much of K&R, for some reason. Chapters 3 and (in this edition) 12 are probably the most fun to work through to gain an understanding of the language.

In the industry I work in, Tcl is used extensively as the application language, and it works out well enough in practise (funnily enough, one of the larger players in this space use a dialect of Scheme.)

I guess the greatest advantage Tcl has is of being embedded deep into peoples workflows (changing which tends to be a huge investment both in terms of money, and what is more valuable, time) so it's very difficult to be dislodged from there. Also, once an EE manages to grok "everything is a string", there's absolutely nothing to stop him from writing horrible code :)

As for advantages, meh. The only one that really stands out for me is this one:

> There aren't a big number of implementations of Tcl, and there is a bigger default library.

Insights on dating habits in Delhi will transfer reasonably well across all the cities (which is probably Ignighter's target audience, anyhow.)

What I'd love to see are the statistics behind this quote:

> Still, 40 percent of Ignighter’s members are women

The conclusion is the most inspiring part of this:

> Real efficiency comes from elegant solutions, not optimized programs. Optimization is always just a few correctness-preserving transformations away

Um, that's actually how I've always heard it said. How is it pronounced, otherwise?

Vim is definitely faster at starting up ;)

For "." you could say that C+k,C+_/C+y does most of what I want done -- and arguably, the more complex cases might be amenable to using regexp-replace.

Regretfully, the only time I ever use hjkl is to play crawl :) The emacs keys are perhaps more geared towards using modifiers, with M-f/M-b + C-f/C-b serving as the closest replacements for movement, and M-z for zap-to-char.

I dunno, I tend to prefer the emacs movement keys over vim. I-search to move around in emacs, in combination with C+A+f/b is (usually) fairly fast - though a fairly good reason for that might be because I know the structure of what I edit. As for someone who moved from emacs to vim, I cannot resist posting this particular link :)

http://notinventedhe.re/on/2010-12-22

You're absolutely right, of course - a webapp in C++ is not something that I'd want to even volunteer to help maintain.

I'd just say that it's not the language that rots, but the libraries, and preexisting code. There are still some areas where C++ is a good choice, but for things like a webapp, there would have to be a really compelling reason to choose it.

Perhaps as a counterexample, when I'm write some linear algebra code that I expect to perform reasonably well, I greatly prefer using eigen to other BLAS implementations (well, except the MKL, but that's a different matter entirely.)

    A lot of people who have written and maintain large C++ code bases will tell you straight up that they prefer C to C++.

Perhaps that's the problem right there. As someone who has written a lot of C++ for quite some time, the most nightmarish aspect tends to be working with antique codebases.

The way people program in it has changed drastically over the last ten or so years. It's possible to have a reasonably painless experience with modern C++ that is pretty much impossible with codebases with significant history.

A lot of that is because the compiler support simply wasn't mature enough, so people did what they had to do to ship. If all you're dealing with is old C++ code, it's extremely easy to find that you prefer coding in C rather than C++ (which is almost what that old code really is).

I believe the banks do offer an alternative to go online and generate an OTP.

Of course, this does defeat the purpose of an IVR transaction :)

For what it's worth, I'm optimistic: the banks might listen to customer complaints and actually do something about it. I admit that I have no idea what they could do: AFAIK there's no way a telco could even guarantee that a SMS is delivered immediately after it is sent