Hacker News Reader

Comment by adamnemecek | Hacker News Reader

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.

View on HN

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!).

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.

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

I see, thank you.

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?

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) 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

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/

Single-file coding is an entire subculture. See leo [1] and org-mode [2] programming.

[1] http://leoeditor.com/

[2] http://orgmode.org/worg/org-contrib/babel/intro.html#literat...

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.

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.

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.

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?

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

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

Reply on news.ycombinator.com