HN user

karatinversion

1,139 karma

SWE for IBM Storage.

Posts6
Comments282
View on HN

There's also the fact that common methods threw exception types that were not final, and in fact overly generic. If I call a method that declares itself to throw NoSuchFileException or DirectoryNotEmptyException, I can have a pretty good idea what I might do about it. If it throws IOException without elaboration, on the other hand...

Oh Shit, Git? 2 years ago

I just tested it by creating a repo with two branches without a common ancestor, and I was able to move a branch pointer to either history with update-ref, so no, I don't think so

No Calls 2 years ago

we don't do commissions, we just pay good salaries

The semi-joke I always heard about this was that if you don't pay commissions, you'll hire a sales team who are good at selling you that they are doing a good job, rather than selling the prodct.

To tie this back to TFA, even before we knew that the Halting problem was uncomputable, we could have defined

  f(n) = { 1 if there is a Turing machine with at most n states that solves the Halting problem;
           0 otherwise }
and we can easily show that f(n) is computable without proving that the Halting problem is undecideable. Viz., f is either constant 0; or equal to a function of the form
  g_k(n) = { 1 if n >= k;
             0 if n < k },
and both the constant 0 function, and all the g_k functions, are computable; thus f is computable.

As I understand it, the C spec defines what are valid programs, and for valid programs, either specifies what their observable side effects must be, or leaves them either unspecified or implementation defined. Importantly, programs with undefined behaviour are excluded from the class of valid programs; thus the spec imposes no requirement on the resulting behaviour. To quote,

Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to […]

And I think this is where “can’t happen” comes in: in the case of undefined behaviour, the compiler is free to emit whatever it pleases, including pretending it cannot happen!

And also, the system is a direct descendant of regnal numbering, where zero wouldn’t have made sense even if invented (there is no zeroth year of Joe Biden’s term of office).

I always thought the problem with this was that the compilers do loads of these optimisations in very mundane ways. Eg if I have a

  #define FOO 17
  void bar(int x, int y) {
    if (x + y >= FOO) {
      //do stuff
    }
  }
  void baz(int x) {
    bar(x, FOO);
  }
the compiler can inline the call to bar in baz, and then optimise the condition to (x>=0)… because signed integer overflow is undefined, so can’t happen, so the two conditions are equivalent.

The countless messages about optimisations like that would swamp ones about real dangerous optimisations.

On top of all the other problems pointed out, java's checked exceptions don't even do a good job of indicating possible failure conditions. The standard library set the tone on this with exception like IOException, which has an enormous amount of subclasses represting different IOExceptions, and is thrown by anything related to IO. So I still need to rely on documenation or code inspection to understand what exceptions might actually be thrown and what they mean, if I want to recover from errors.

The classic case of this is that the compiler cannot tell that

    new StringReader("Example").read()
doesn't throw an SSLException.

The version of rigorous infinitesimals I've seen didn't let you have these identities, because e^2 != 0 (because it still maintains the field axiom xy = 0 => x=0 V y=0); but the argument still goes through by carrying the whole power series in place of these simplifications – you can write the higher order terms as e*f(x, e) and drop them when you evaluate st(...).