Hacker News new | past | comments | ask | show | jobs | submit login
Problem Solving and Clojure 1.9 (2018) (github.com)
95 points by tosh 58 days ago | hide | past | web | favorite | 5 comments

> I think a big problem is you grab a library and you really have no idea what you've gotten. Maybe it has a label. It says it's 1.2, but you don't know which functions inside it have changed, or why. You don't actually know what you're running. And maybe the jar file or artifact tells you something about the source that was used to produce it, but the process that was used to produce it is often opaque. And any of that could be wrong because there's a lot of human steps involved in producing artifacts. And because so many people use Git, I'd like to get closer to leveraging some of the features there, in particular using SHA's and content-based addressing to talk about things.

> I had worked on a library called Codeq, which we'll have a new version of soon, that sort of extends the Git model down to the function level, so you would have SHA's for individual functions, and you could have dependencies on functions, instead of on artifacts. So a lot of work is happening around that, and some of that manifests itself in this dependency tool.

Joe Armstrong proposed something similar for Erlang:


Similar to what Unison is doing. Functions are identified by a hash and the names are ephemeral.

It took a moment to google what Unison is. Apparently a new programming language: https://github.com/unisonweb/unison

Somehow these comments reminded me of a rant by John von Neumann. In an essay he says something like "mathematics is actually very shabby, just have a look at the extremum principles. Extrema? So we can't even tell if it's a minimum or a maximum?" It amuses me how software developers think of themselves as precise, when, actually, there is a lot of shabbiness in sw development. Hickey's example is one.

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