2 ms·
Other people have already commented on the core message. I have a nitpick instead: > That's probably why we still have textual source (great for git and mergin
by majewsky 7y ago
Other people have already commented on the core message. I have a nitpick instead:
> That's probably why we still have textual source (great for git and merging) over more expressive formats or even the old idea of serializing the entire state of a VM (again lisp, smalltalk) which sacrifices merging entirely to make hotpatching (dynamic software updates) trivial.
Good. Not being able to merge squarely belongs in the past, where everyone had access to only one machine. I'm incredibly thankful that I can merge the half-finished work on my desktop from last evening with the patches that I just pushed from my notebook while in the train.
- DagAgren 7y agoMore expressive representations of source code enables better merging. Merging code as opaque strings of text is a bad choice, and causes lots of problems to programmers every day.
- majewsky 7y ago> More expressive representations of source code enables better merging. Merging is usually easy regardless of representation when all changes are comparatively local. The problem is always merging big far-reaching changes like a complete refactoring of an entire module, and I don't immediately see how any non-text representation would do significantly better (by a wide-enough margin to justify changing paradigms) than text at assisting with the merge process in this case.
- DagAgren 7y agoHave you never got large merge conflicts because one branch made some changes to a block of code, and the other left it intact but changed its indentation? That kind of thing would not happen in a better representation.