lomnakkus

In a former life I worked with a codebase that used that style. Let's just say it isn't enough.

No, but you can easily end up missing some because somebody wrapped them in some sub-type of RuntimeException because they were forced(!) to. This happens all the time because the variance on throws clauses it at odds with the variance of method signatures (well, implementations, really -- see below).

A new implementation of a ThingDoer usually needs to do something more/different from a StandardThingDoer... and so may need to throw more types of exceptions. So you end up having to wrap exceptions ... but now they don't get caught by, say, catch(IOException exc). If you're lucky you own the ThingDoer interface, but now you have a different problem: It's only JDBCThingDoer which can throw SQLException, so why does code which only uses a StandardThingDoer (via the ThingDoer interface) need to concern itself with SQLException?

Checked exceptions in Java are worse than useless -- they actively make things worse than if there were only unchecked exceptions. (Because they sometimes force the unavoidable wrapping -- which every place where exceptions are caught needs to deal with somehow... which no help from the standard "catch" syntax.)

Parent poster explicitly said "under pressure". What more do you want?

> Copying is encouraged. Like I said, having the algorithm there is a good way to make it apparent what the code is actually going to do and the associated cost of the solution.

It's also a good way to make bugs proliferate throughout your code base. IIRC bug count correlates well with line count regardless of the language(!).

Present tense -- it's (almost?) always a little shorter, so you can fit more information into the "subject" line.

Using min() seems like it could be incredibly dangerous as an "implicit" behavior, not to mention surprising.

I'd wager it'd be much better to just specify that abort() gets called in the "overflow" case. (Given that overflow is basically never what you want anyway.)

Yeah, it'll crash but at least it won't be suprising/undefined behavior.

> IMO Lambda calculus should be taught wider in CS programs. It brings useful models, builds (if one likes theory) good background to functional programming paradigms, etc.

I'm surprised than anyone thinks this. Unless you're in a very specialized area, it's about as useful as getting practice with writing algorithms using Turing Machines.

(Yes, it offers a very different perspective to the usual Von Neumann machine, but learning graph reduction as evalation is just as valuable, if not more.)

Honestly, it seems like a pretty clear intention to co-opt a term ("commons") which has usually meant "let's share things!" to mean something entirely different. (And shame on them for doing that.)

I believe it may be because the email only mentioned Intel explicitly and had a "I won't be buying Intel in future" (paraphrased) comment. However, I personally wouldn't assume that AMDs HT implementation doesn't have similar issues.

If I were being pithy, I find that when you're doing this type of thing it's more a feeling of "working fun" rather than "working hard".

(Of course this means that one is probably not always going to do "production ready" things, but it's for fun, so it doesn't really matter. Sometimes it's fun to just go nuts and sprinkle "undefined"[1] all over the code base and just go from types to implementation as fast as humanly possible.)

[1] This is a Haskellism, but basically means any of:

    assert(false)
    throw new NotImplementedException(...)
    ???
    etc.

I think you mean the "biosphere" rather than "we". Modern humans have existed anywhere from 50k-200k years. Just to put the time scales into context.

EDIT: Just to clarify: As long as disasters happen slowly enough and there are actually local maxima for the species to evolve "into", everything may be fine for "humans"... but those assumptions may be overly optimistic.

If the array structure itself were being modified, the "i < a.length" check would have to be done every iteration, but in this case there's no mutation of the array itself, so it's OK to move "a.length" to a constant outside the loop... and from there it's trivial to move bounds checks outside the loop (and from there: eliminate them entirely)

I suppose that's true in some sense, but at least string theorist have done some interesting math?

(It may not be math that applies to the real world, but math being math is eternally valid as long as the axioms hold... and sometimes you get surprising applications later on.)

Damage-by-software usually isn't spectacular (and therefore not likely to get noticed) or not necessarily very directly costly in terms of human lives, but I'd argue it's actually more significant in the long term and in the grand scheme of things. Software rules everything and even slight errors or inefficiencies have absolutely incredible incidental cost.