army

There's a difference between being enthusiastic about working for a company and being so keen to work to them that you're not even going to consider alternate offers. But seriously, you think that someone is going to be a bad employee just because your company isn't their one true love in the world?

I don't really think there's a justification for exploding offers that prevent people from considering alternatives, it's mainly just a way for employers to attempt to get the upper hand. From what I've seen it's often a) arrogant employers who can't comprehend that they're not the only attractive place to work b) game-playing employers who know that most college-age people aren't going to stand up to unreasonable demands and that these sort of gambits can prevent them from having to actually compete directly with other employers c) employers who do have an urgent need to fill a position (i.e. who aren't hiring an intern).

I would agree with his approach, but unfortunately the Python community has encouraged, to some extent at least, the use of implicit "truthiness" to do things like check for None, rather than explicit checks.

It's probably easier to get it in when you're solving a real problem.

It's also a specific instance of a more general technique of incremental computation, which is, if you look at it from the right perspective, a more specific instance of integration: rather than computing a function directly, you're computing the differences and then integrating. So you could almost say that the method dates back to the 18th century: http://en.wikipedia.org/wiki/Euler%27s_method.

It's definitely one of those tricks that comes in handy now and again :).

That was far funnier than it had any right to be.

Very cool. I think the point about transcribing equations directly from papers glosses over some of the hard issues with building numeric libraries around floating point precision and numeric stability.

It's not that uncommon to see code that would have worked perfectly if double precision floating point numbers were actually real numbers, but which blows up badly once rounding errors happen.

Unfortunately there's not really any way to abstract those issues away. In general, I'd hope that any the authors of widely used numeric libraries have carefully thought through these issues.

Based on the experience I've had with teaching programmers, most don't have the distinction clearly in their mental models. For most of basic things they might do it can be made to work either way: usually with a bit of fiddling they can make it work. Of course, this doesn't work at all as soon as you start trying to implement data structures.

I've seen some awkward code too from people moving from Java to C++ where either they make everything a pointer, or they use value objects without understanding that they're not references.

The problem is once you touch those memory pages, total memory usage increases even if you don't call malloc.

In Java, all methods are virtual. You can often achieve a similar effect to non-virtual methods by declaring them final to prevent them being overridden in subclasses, but the same rules about which method is called apply. The reason to simplify the language (in comparison to C++) - the rules about which method are called are much simpler and easy to remember.

This is less of a problem for systems with JIT compilation (including Java, C#, etc). They can recompile the code at runtime, which allows some nice tricks for virtual calls. They can turn a virtual call into a regular call with inline caching (http://en.wikipedia.org/wiki/Inline_caching), or can even compile a specialized version of the code for a given type and inline the entire virtual function.

Agreed, for almost all code it doesn't matter, but for the remaining small fraction it's worth thinking about these things. It sounds pretty insane to go with a blanket approach of removing virtual calls throughout an entire codebase without understanding which ones are the problematic ones. Especially since some ways of solving the problem could potentially lead to other problems like increased compiled code size.

I've seen plenty of software (especially systems software) that does spend much of it's time in tight inner loops. Pulling out all the optimization stops there can give measurable gains. I've personally seen measurable gains on real applications from tricks like reordering branches so that the more predictable branches go first.

I think day-long interviews are fine, and I think real-world work samples are fine, but the combination is pushing it a bit as far as what is fair to ask job applicants to do, unless you're going to have some sort of explicit and upfront agreement about a trial period.

Thanks for reminding me of that quote - it's rare you find some much hilarity packed into a single sentence.

The market is so volatile at the moment, especially with speculative momentum traders, that it's hard to say what would happen. There's no real way to value Bitcoin on fundamentals, so there's nothing much to keep the market stable around a particular valuation.

There's a far stronger floor though on the price for Google shares, given that they're a very profitable company with good future prospects. The share price doesn't have to drop too much before it starts looking like a bargain to the many deep-pocketed stock market investors out there. With Bitcoin the value is so speculative at the moment that I think, if anything, a sell-off that large would trigger a self-sustaining run on Bitcoin.

That isn't really an accurate description of the issues: it's not the case that it was "working" and then "broken" by GCC maintainers. It's always been unsupported and not worked in specific situations, but for 99% of code it appeared to GCC users that it was supported. The signed integer overflow behaviour was never guaranteed by old versions of GCC, and code exploiting it would not always be compiled with the "expected" behaviour. It's just as the GCC optimizer has improved there are more circumstances when it does optimisations that hinge on the assumption.

Compiler users generally want something that "just works" and doesn't do anything unexpected, but in the case of a low-level language like C, doing away with undefined behavior essentially would mean pessimistically avoiding many optimisations on the 99%+ of straightforward, reasonable code out there in favor of not doing anything surprising on the remaining fraction of dubious code that depends on certain things happening in scenarios where behavior is undefined according to the C standard. There are languages that make that choice, but C isn't one of them.

We had to use RCS for university projects and submit the versioned files. It has many shortcomings but the simplicity of it is nice for some purposes.

Stonebraker is a very smart person but he's also not shy about promoting his own companies/research. You generally get a well-informed but very opinionated take on things from him.

VoltDB, for example, is good for certain complex workloads over large but not-too-large data sets. For a lot of situations it isn't really an alternative to memcache+MySQL or a NoSQL solution.

InnoDB isn't anything like that - it's a transactional database engine that's been around since the 90's and has since become the standard storage engine for MySQL - it competes directly with Postgres' storage layer.

I find git's CLI pretty efficient: most of the time it is just commit/rebase/push/pull.

Consider yourself lucky :). I've just learnt things as I've come across new and difficult situations.

The issues are really in dealing with multiple concurrent streams of development (multiple developers, or different branches of your own development if you have to switch between tasks). It's also useful having good tools to look at diffs and history to try to diagnose any problems.

DVCS's solve a hard problem where there isn't a single obvious way of thinking about it. There's no easy solution to managing multiple concurrent streams of development. And everyone has their own different ideas about what's the best way to solve it.

I've used tools that are "simpler" than git: subversion for one. My experience has been that this simply means that they don't handle more difficult version control scenarios that do occur in practice. Subversion, in particular, just has a tendency to throw up it's hands and leave you to manually merge changes in any non-trivial merge scenarios.

The political system in Singapore also makes me uncomfortable: it's superficially democratic but not really in spirit.

I spent at least an hour a while ago trying to track down a bug that turned out to be caused by exactly this. I couldn't work out what was happening until I looked at the preprocessor output.

I can see why she might have been flagged for closer investigation: someone from the Phillipines with lots of family in the U.S. is probably a high risk of overstaying, but it sounds like the way it was conducted was totally out of line.

The right to creatively interpret the constitution?

Oracle sold a product that was absolutely essential to pretty much every major business: there isn't really a good alternative to a transactional relational database running on middle-to-high-end hardware for a lot of companies. Selling something business-critical to customers with deep pockets is a pretty good business strategy. And they only had a couple of direct competitors in that space.

This isn't that surprising. It's common knowledge in the academic community that:

* There are bogus open access journals which exist solely to make money from author fees.

* There are bogus conferences that follow a similar business strategy.

* There are lower-quality journals and conferences that do not attract many top-quality submissions, so tend to have a lower barrier for acceptance: you might get work that's rigorous and unexciting, work that's exciting but preliminary or rough around the edges, or work that's neither rigorous nor interesting.

* Peer reviews vary widely in quality, from being thorough to overly critical and nit-picking to being cursory. This is extremely frustrating to many people, but is hardly an undiscussed issue. One particular problem is that more junior reviewers are often reluctant to criticize a paper unless they're very confident in their understanding, either due to it being slightly outside of their core expertise, or due to convoluted presentation: it's easier to assume it's correct than to go out on a limb criticizing something.

I would say that being published in a peer reviewed article is just the start of a gauntlet that any serious scientific claim has to run, regardless of the quality of peer review. Plenty of important work has started out as being extremely controversial: even once it got published people didn't necessarily think it was right. The consensus does continue to evolve.

I've never met a scientist who will believe something just because it's in a peer reviewed article.

I've had many times where I swore that something was a compiler bug. I did hit one once with Haskell/ghc, but I think that is the only instance.

It depends on your technique. If you have the technique down it isn't difficult to rapidly decelerate on hills. It's mainly just a matter of bracing yourself, keeping your centre of gravity back and modulating the brake.

If you're not prepared for it and slam the front brake on your weight will shift forwards and you'll have lift off.