Hacker Newsnew | past | comments | ask | show | jobs | submit | phillord2's commentslogin

I am using the term "ontology" to mean "a description of truth", and "epistemology" to mean "how do we know what truth is". Of course, these are philosophical definitions, which (as the article says) are not necessarily that applicable.

The article in question uses OWL -- which is a subset of first order logic -- to illustrate the point. Clojure is (in this article) just a syntactic wrapping.


Ah, that certainly makes sense. The article was a hoot, BTW - speaking as both a philosophy geek and food geek.


Thank you!


That is not what is happening with SLF4J. The nop logger is present in the API artifact. The API artifact chooses to warn when using it. The nop dependency, despite the name, contains no logger at all. It just explicitly forces the usage of the nop logger.

It's pretty clever actually, and works in a straight-forward way.


It's a set of clojure code that I expect people to use in an interactive shell by, yes, calling methods. Whether people do that within an IDE, directly at a REPL or by running a script is up to them.

I'm still not understanding why I should perform major surgery on my tool for the sake of a logging library which is a transitive dependency.

Nor am I understanding why I should pass the error message that confused me on to downstream users. I'm happy to make the decision rather than sit on the fence.


My point is that "not passing on the error message" could make life harder for downstream users too, depending on who those users are. (Sorry if my reply was arrogant or harsh - I got burned by this in the past, that's why I'm telling it)

If you're developing a project and use SLF4J by yourself, and use a third-party-dependency that already includes a logger implementation, this dependency can override your logging and cause all sorts of havoc. This can be a frustrating and hard to find bug.

(I'd say the fact that this can happen at all is a design flaw in it's own, partly caused by Maven's way of dependency resolution, partly by SLF4J. But I don't see that changing in the near future...)

I think it's important to consider how your project will be used. if it's really just for exploratory use in a REPL/a few scripts, then including a logger is fine. If you think this project could be used in larger projects, you should consider leaving it as it is or restructuring.

If you do include a logger, leave a note about it in the documentation. This way, users can at least exclude it again if they have to.


Java is getting an interpreter shell, as it happens.

Logging should default to warn/error on standard err? I find this a strange idea. Having a "--verbose" switch is pretty standard on the command line. Some applications do have an "be absolutely silent" switch, true but that normally switches everything off.


The alternative is not specifying a nop dependencies and then inflicting on downstream uses the choice that I was not prepared to make.


It was a mistake. The tag wasn't pushed is all.


I'm not convinced I was at ISMB 2012 to be honest:-)

Should be there for 2015!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: