Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never edit a method, always rewrite it?

dave.cheney.net

Post reply on HN
Print view View original

11–20 of 120 posts

Re: Never edit a method, always rewrite it?

#11

Post by mhomde »

adamnemecek wrote: post #8

I've been doing something similar. I name the new method Method, rename the old one as MethodOld and in Method, before the return value, I put an assert(MethodOld(args) == return value). It's one of the things that when I do, I appreciate the value of, but I'm not disciplined enough to do as much as I would like to lol.

That's actually a good idea, thanks! I'm not sure it would be feasible but it would be neat if methods was automatically versioned (in all but syntaxtic changes) and you could automagically compare results of the different versions.

It kinda falls apart with refactoring but still :) I'm finding it more and more evident that file's as the default unit of storage and viewing of code is an obsolete concept

Re: Never edit a method, always rewrite it?

#12

Post by jstewartmobile »

eropple wrote: post #6
jstewartmobile wrote: post #4

Coming from EE, I like the thinking behind this. Components are similar to functions, they are tested to the nth-degree out of inventory, liability, and other concerns, and everything goes along well enough. What would really help for that style of development would be a sort of apropos feature for your own code where you could look up methods by keywords rather than just identifiers. For larger projects, having peop…

Literate programming, as a concept, is super interesting. But it has a fundamental problem, when applied to software-as-an-industry, that I think is difficult to solve: many, if not programmers, may be literate but are not literate enough . If you go look at a Knuth example of literate programming, there emerges a few fundamental capabilities. One: the ability to look at code fresh, as if it were to someone wholly un…

True enough, though at this point I'd be grateful for any kind of consistent method-to-description binding.

Having it be compiler enforced would also be nice. Even if most of the descriptions end up along the lines of "do some stuff with the string", at least that's something.

Re: Never edit a method, always rewrite it?

#13

Post by EGreg »

I had a different rule, which I was advocating for PHP 5.3 back in the day:

Have functions take regular parameters and the last one will always be an associative array of options.

This matches how functions evolve. You have some required parameters, then introduce more but the old callers don't know about them so they're optional.

I was trying to argue that PHP could unify the function call syntax and array definition syntax to encourage this. In other words the options would actually be virtual, as the caller would just supply the optional named parameters at the end of the function.

Re: Never edit a method, always rewrite it?

#14

Post by erikpukinskis »

robbiep wrote: post #7

The metaphor that biological systems undergo continuous renewal and so therefore code should be rewritten not edited i think is actually off, code is the dna and thus undergoes evolution not replacement

The DNA is rewritten from scratch each new generation.

It even gets rewritten over and over during the life of a single cell.

Re: Never edit a method, always rewrite it?

#15

Post by gjjrfcbugxbhf »

js8 wrote: post #9

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 ver…

Why? Your revision history is already in version control.

Re: Never edit a method, always rewrite it?

#16

Post by seizethecheese »

mhomde wrote: post #11
adamnemecek wrote: post #8

I've been doing something similar. I name the new method Method, rename the old one as MethodOld and in Method, before the return value, I put an assert(MethodOld(args) == return value). It's one of the things that when I do, I appreciate the value of, but I'm not disciplined enough to do as much as I would like to lol.

That's actually a good idea, thanks! I'm not sure it would be feasible but it would be neat if methods was automatically versioned (in all but syntaxtic changes) and you could automagically compare results of the different versions. It kinda falls apart with refactoring but still :) I'm finding it more and more evident that file's as the default unit of storage and viewing of code is an obsolete concept

> I'm finding it more and more evident that file's as the default unit of storage and viewing of code is an obsolete concept

Fascinating. Could you expand on this or link somewhere?

Re: Never edit a method, always rewrite it?

#17

Post by js8 »

gjjrfcbugxbhf wrote: post #15
js8 wrote: post #9

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 ver…

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.

Re: Never edit a method, always rewrite it?

#18

Post by conradk »

adamnemecek wrote: post #8

I've been doing something similar. I name the new method Method, rename the old one as MethodOld and in Method, before the return value, I put an assert(MethodOld(args) == return value). It's one of the things that when I do, I appreciate the value of, but I'm not disciplined enough to do as much as I would like to lol.

That's interesting ! Will try that sometime. One question though: how do you deal with mutating methods? Like methods that would persist a value to storage and only should do so once?

Re: Never edit a method, always rewrite it?

#19

Post by cdancette »

erikpukinskis wrote: post #14
robbiep wrote: post #7

The metaphor that biological systems undergo continuous renewal and so therefore code should be rewritten not edited i think is actually off, code is the dna and thus undergoes evolution not replacement

The DNA is rewritten from scratch each new generation. It even gets rewritten over and over during the life of a single cell.

It gets copied, not rewritten. This is the same with software that gets copied to machines so that we can run it.

Here we're talking about modifying a specific function, not duplicating all the code.

Re: Never edit a method, always rewrite it?

#20

Post by rootlocus »

js8 wrote: post #17
gjjrfcbugxbhf wrote: post #15

Earlier quoted context omitted.

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 wan…

Sounds similar to https://thedailywtf.com/articles/best-of-2016-the-inner-json...

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.

Post reply on HN