Hacker News Reader

Comment by js8 | Hacker News Reader

I had a similar idea some time ago, that all the code should be write only. That is, you should always write new functions (and give them new names) instead of trying to rewrite them (if the spec changes, this assumes they were correct in the first place).

I think it's only really doable in purely functional language (like Haskell), though. It sort of means versioning of individual functions, and also types. It's very similar to rebinding values only as opposed to modification of variables.

But naming is a problem. Maybe.. There are two kinds of names of types and functions - intrinsic and extrinsic. Intrinsic name only describes what the thing is (e.g. array.search()). Extrinsic name relates to the problem being solved (e.g. product.findByPrice()). Maybe the functions (and types) that have only extrinsic names should be versioned and short name should be assigned to the latest version.

All in all, I think it's a concept worth researching.

View on HN

I strongly disagree with this. I've been deleting thousands of lines of this sort of code recently.

It creates technical debt and someone else will have to clean it up

I've heard of a few systems that help you manage this kind of thing.

Most people use git, but there's also cvs, svn, hg, perforce, bzr, and probably some others in use that I'm forgetting.

Leave the history to those tools, they make it easy to change things as much as you'd like without losing work.

Don't work against them with policies like this.

Why? Your revision history is already in version control.

With VC, you can only call the latest version. With versioned functions, all the old code would still call the old functions, until you would explicitly refactor it (or type system would fail).

I guess there is a philosophical debate behind this - what's in a name? Should a name of function refer to a specific body of code only, or all possible function bodies, past and future? What did the caller of the function want?

You can only guarantee correctness if the former. But the latter gives you more flexibility. I am not saying that this is the right answer.

Keeping all versions of the same method in the source files has a lot of drawbacks:

1. Readability. Autocomplete gives me 50 versions of that method. Which one do I choose? The latest? Why do the rest need to exist?

2. Code size. Can you imagine the compilation times? IDE indexing times? Binary size?

3. Consistency / Correctness. How do you know when each call should update it's version. How do you increment all calls to the latest version?

Simplicity is the ultimate sophistication.

You could see this proposal as tighter integration between version control and the language proper, which has the potential to solve a lot of problems. E.g. there's a common problem with diamond dependencies: if A depends on B and C, and B depends on D, and C depends on D, what do you do if the versions of D they depend on don't match?

You should give PHP a try!

Reply on news.ycombinator.com