4 ms·

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(MethodO

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.

mhomde 9y ago
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
- seizethecheese 9y ago
  > 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?
  - mhomde 9y ago
    It's just a general thought I've been having. We're using text and files because it's the way things always have been. But it seems there should be benefits to perhaps move beyond that. Things like with more canonical representations of code, rather than arguing over coding standards (although it can still text-based rather than completely graphical). Ability to more easily see related code and flows. Manage the meaning of code rather than its text (not changing text but changing symbols when you refactor). There's been attempts to move in that this direction with things like code bubbles (https://www.youtube.com/watch?v=PsPX0nElJ0k https://www.youtube.com/watch?v=PsPX0nElJ0k) but yet there hasn't been an approach that's both visually attractive and offers enough benefits, but it's probably coming somewhere down the line
    - timthelion 9y ago
      Code bubbles is hands down the most awsome thing I've seen in months! Where can I get it? I'll switch to JAVA for this? Thanks for sharing. Edit: to answer my question, yes this really exists http://cs.brown.edu/~spr/codebubbles/ http://cs.brown.edu/~spr/codebubbles/
  - timthelion 9y ago
    Single-file coding is an entire subculture. See leo [1] and org-mode [2] programming. [1] http://leoeditor.com/ http://leoeditor.com/ [2] http://orgmode.org/worg/org-contrib/babel/intro.html#literate-programming http://orgmode.org/worg/org-contrib/babel/intro.html#literat...
conradk 9y ago
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?
- lloeki 9y ago
  In some cases you can mutate one of them to a noop (like /dev/null for a file, a stub class...).
smt88 9y ago
There's a better way to do this. Write a unit test for Method and just edit Method as needed. Run your test to verify that the output is consistent. This prevents cluttering your code with old methods and also allows you to figure out if a new environment breaks your code.
- nitrogen 9y ago
  Yes, please just do this. Maybe this thread is full of Poe's Law irony, but if not, I don't look forward to refusing to work on any code developed with the practice of strewing almost-the-same methods all over the place. Simple code scales. Write simple code.
lloeki 9y ago
For some hairy stuff that require live data you can also reverse the practice: call both yet return the old one, and gather data in production before switching. Obviously this does not work for side-effectful methods (beware of caches!).
- dotancohen 9y ago
  I'm interested in what fields you would use this methodology. Machine learning? In most fields we have a sample of known input vectors, including edge cases, that map to known outputs. A unit test is enough to test these methods with different implementations.
  - karlding 9y ago
    An example of when you might use this is when you're cutting over to a new service, and you want to validate that the new service behaves the same way as the old one before transitioning all the traffic to the new service. In order to build confidence in the new service, you can assert that the expected output is the same, and raise alerts when there is an inconsistency. This incremental rewrite approach allows you to slowly replace pieces of an application with a new service and helps prevent regressions in behaviour. Or consider when you're performing a database migration (on large databases) with 0 downtime. Typically this involves something like: 1. Dual Writing: Create 2 tables and write to both and keep them in sync (by duplicating new data, and back-filling old data) 2. Update read paths: Change all code to read from the new table, and validate that the data being read is consistent with the old table. You can use a library like Scientist [0] to validate that the reads are the same. 3. Update write paths: Change all code to write to the new table (and raise alerts if the old path is exercised) 4. Deleting old data: Remove code and data that relies on the old data model [0] https://github.com/github/scientist https://github.com/github/scientist
    - dotancohen 9y ago
      I see, thank you.
sitkack 9y ago
It would be nice if our language/tooling/runtimes could assist in this. Same thing for version diversity in microservices.
SatvikBeri 9y ago
In some languages you can use property-based testing to generate thousands of inputs and check that Method(x) == OldMethod(x). See Hypothesis for Python, QuickCheck for Haskell, ScalaCheck for Scala, etc.

mhomde 9y ago

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

seizethecheese 9y ago
> 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?
- mhomde 9y ago
  It's just a general thought I've been having. We're using text and files because it's the way things always have been. But it seems there should be benefits to perhaps move beyond that. Things like with more canonical representations of code, rather than arguing over coding standards (although it can still text-based rather than completely graphical). Ability to more easily see related code and flows. Manage the meaning of code rather than its text (not changing text but changing symbols when you refactor). There's been attempts to move in that this direction with things like code bubbles (https://www.youtube.com/watch?v=PsPX0nElJ0k https://www.youtube.com/watch?v=PsPX0nElJ0k) but yet there hasn't been an approach that's both visually attractive and offers enough benefits, but it's probably coming somewhere down the line
  - timthelion 9y ago
    Code bubbles is hands down the most awsome thing I've seen in months! Where can I get it? I'll switch to JAVA for this? Thanks for sharing. Edit: to answer my question, yes this really exists http://cs.brown.edu/~spr/codebubbles/ http://cs.brown.edu/~spr/codebubbles/
- timthelion 9y ago
  Single-file coding is an entire subculture. See leo [1] and org-mode [2] programming. [1] http://leoeditor.com/ http://leoeditor.com/ [2] http://orgmode.org/worg/org-contrib/babel/intro.html#literate-programming http://orgmode.org/worg/org-contrib/babel/intro.html#literat...

conradk 9y ago

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?

lloeki 9y ago
In some cases you can mutate one of them to a noop (like /dev/null for a file, a stub class...).

smt88 9y ago

There's a better way to do this. Write a unit test for Method and just edit Method as needed. Run your test to verify that the output is consistent. This prevents cluttering your code with old methods and also allows you to figure out if a new environment breaks your code.

nitrogen 9y ago
Yes, please just do this. Maybe this thread is full of Poe's Law irony, but if not, I don't look forward to refusing to work on any code developed with the practice of strewing almost-the-same methods all over the place. Simple code scales. Write simple code.

lloeki 9y ago

For some hairy stuff that require live data you can also reverse the practice: call both yet return the old one, and gather data in production before switching. Obviously this does not work for side-effectful methods (beware of caches!).

dotancohen 9y ago
I'm interested in what fields you would use this methodology. Machine learning? In most fields we have a sample of known input vectors, including edge cases, that map to known outputs. A unit test is enough to test these methods with different implementations.
- karlding 9y ago
  An example of when you might use this is when you're cutting over to a new service, and you want to validate that the new service behaves the same way as the old one before transitioning all the traffic to the new service. In order to build confidence in the new service, you can assert that the expected output is the same, and raise alerts when there is an inconsistency. This incremental rewrite approach allows you to slowly replace pieces of an application with a new service and helps prevent regressions in behaviour. Or consider when you're performing a database migration (on large databases) with 0 downtime. Typically this involves something like: 1. Dual Writing: Create 2 tables and write to both and keep them in sync (by duplicating new data, and back-filling old data) 2. Update read paths: Change all code to read from the new table, and validate that the data being read is consistent with the old table. You can use a library like Scientist [0] to validate that the reads are the same. 3. Update write paths: Change all code to write to the new table (and raise alerts if the old path is exercised) 4. Deleting old data: Remove code and data that relies on the old data model [0] https://github.com/github/scientist https://github.com/github/scientist
  - dotancohen 9y ago
    I see, thank you.

sitkack 9y ago

It would be nice if our language/tooling/runtimes could assist in this. Same thing for version diversity in microservices.

SatvikBeri 9y ago

In some languages you can use property-based testing to generate thousands of inputs and check that Method(x) == OldMethod(x). See Hypothesis for Python, QuickCheck for Haskell, ScalaCheck for Scala, etc.