5 ms·

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

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."

vimota 10y ago
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?
- awwaiid 10y ago
  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.
  - bpicolo 10y ago
    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.
    - dragandj 10y ago
      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.
      - mcguire 10y ago
        If it's good enough for ANSI C, it's good enough for you...
      - bpicolo 10y ago
        Matters so rarely that it's far better to rewrite in those cases when necessary.
        dragandj 10y ago
        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.
  - maherbeg 10y ago
    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.
- hyperpape 10y ago
  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.
  - mcguire 10y ago
    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.
    - hyperpape 10y ago

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."

vimota 10y ago

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?

awwaiid 10y ago
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.
- bpicolo 10y ago
  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.
  - dragandj 10y ago
    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.
    - mcguire 10y ago
      If it's good enough for ANSI C, it's good enough for you...
    - bpicolo 10y ago
      Matters so rarely that it's far better to rewrite in those cases when necessary.
      - dragandj 10y ago
        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.
- maherbeg 10y ago
  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.
hyperpape 10y ago
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.
- mcguire 10y ago
  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.
  - hyperpape 10y ago