Hacker News Reader

Comment by bachback | Hacker News Reader

what an annoying post. no real content, but an author desperately trying to prove he's smart.

"To say that I was treated pretty shabbily by David Nolen on this issue almost goes without saying."

I would say he backs up his claims quite well, unlike your comment. He gave ample evidence at his frustrations with the progress of the language - what did you find annoying about it?

I see a lot of issues but not a lot of PRs. As a maintainer there is a lot of prioritization going on, and it seems that the things that bother the blog author are not things that bother the maintainers. I also agree with some of the replies on the issues - garbage in garbage out for a function is ok behavior.

One of the cool things about clojure and other languages like this is that these things can often be fixed at runtime - so even if your fix doesn't get accepted you can have a "my-better-fixes" lib you pull in for yourself. A "consistent-set-opts" lib you add to your project.cls for example.

In what way is "garbage in garbage out" better than consistent handling and explicit failure, especially for something so well-defined mathematically? That's sort of a lazy argument, imo.

I shouldn't need to pull in more libs for baseline language expectations, either. Core libraries are what languages really are, much more important than just syntax.

Because checks to avoid some kinds of garbage can incure significant performance penalty. There is always a tradeoff in that sense, and I think Clojure is pretty well balanced in that way. So, read the docs, try the functions out to see how they work, write tests, and sanitize the data at the appropriate place.

If it's good enough for ANSI C, it's good enough for you...

Matters so rarely that it's far better to rewrite in those cases when necessary.

In core libraries? If low-level functions checked the inputs for each odd case, they'd (often unnecessarily) spend 90% of time doing those checks.

I strongly disagree with garbage in, garbage out. We as programmers and engineers should strive for better tooling in all aspects. I firmly believe that reducing footguns and making our tooling help nudge us in the right direction are extremely important qualities.

I clicked through to the github exchange he links to, and I don't think you can call that shabby treatment. Perhaps a bit too terse (though I don't think so), but it's just saying "the docs say data must meet requirement X, and that's good enough".

His other examples sound prima facie troubling (I don't know enough clojure to have a real opinion), but he's miss-characterizing that interaction.

Once upon a time, many years ago, I was taking a database implementation class at the same time as working as a sysadmin of the university. We started having a weird problem with our AIX 3.2.5 (...years ago...) machines: the NFS subsystem would deadlock and become a tar-baby; any process that touched the affected filesystem would block, including other users' processes, system processes, and (the important part) the automounter. As a result, the boxen were effectively unusable until rebooted. Considering that they were serving 8 x-terminals and remote users, that was a problem.

We eventually narrowed it down to students working on their DB implementation projects, and further to the use of mmap. If you mmap'ed a region larger than a physical file and wrote to the outside region, that NFS filesystem went belly-up. Yes, that's explicitly mentioned as a thing not to do in the mmap documentation. (On the other hand, it worked fine on a local AIX filesystem and in fact was how local file systems extended files; I'd spent the previous couple of years working with AIX filesystem developers.)

Anyway, after getting the professor to tell the students not to do that, I notified IBM tech support. The response I received was exactly, "the docs say data must meet requirement X, and that's good enough".

In a sudden fit of ethics (honestly, I have no idea what came over me), I completely failed to advertise the nifty denial-of-service attack widely. It would have been spectacularly amusing to embarrass my former employer on BUGTRAQ, say. Not to mention imagining the face of the tech support guys when they tried reading their "good enough" spiel to an IBM customer who had more than our handful of machines.

On the other hand, AIX 4 was a complete re-write and fixed the problem with the NFS filesystems. Yay.

Anyway, the bottom line is that using documentation to cover your ass for implementation infelicities is not a very good idea.

This is a nice example of when that's a garbage answer. But I wasn't saying Nolen gave a technically sound answer (not denying it either--it all depends on the details of the case and the consequences). I just meant that it wasn't shabby treatment--if his technical judgment is wrong here, that wouldn't make him a jerk.

The thing is that "the documentation says not to do that" is almost always a garbage answer---even when the docs say it in big flashing letters, like mmap. A good interface should never produce garbage, even when fed garbage. In those cases where it's a necessary answer (say, the interface has no way to have the information necessary---which certainly doesn't apply here), Nolan's answer was completely insufficient and demonstrates a serious lack of respect for the poor sot who spent the time to report the issue.

Reply on news.ycombinator.com