3 ms·

>meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to

>meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to be "live". Why shouldn't code be the same way? It's bad enough for anything but some quick notes, but it sounds like a nightmare for code. >Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes? Nobody stops you from auto saving and running a build every time a files change (I actually did this for my thesis in Latex). IMO this has nothing to do with Git.

atombender 4y ago
Of course you can automatically trigger builds on save; my point is that there's an entire shift in thinking that's possible if we treat development as less of a sequence of discrete "stop the world" actions and more as a continuous loop. As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality. It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be.
- CorrectHorseBat 4y ago
  >As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality. That's a job for the testsuite then, I don't want my version control system to require language specific knowledge. It is also a very hard problem if you want to do it 100% correct. Impossible I would say. >It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be. I really don't understand how that could work or why you even want it in the first place. It sounds like a nightmare to me. I want to be able to make some local changes, stage them, maybe commit and rebase and finally review and push. For very simple documents live editing works great, but for bigger ones it sucks. I would love to see documents move to the git workflow. Imagine a Word document or an Excel table with an automatically generated version history table from commits, that would be great.

atombender 4y ago

Of course you can automatically trigger builds on save; my point is that there's an entire shift in thinking that's possible if we treat development as less of a sequence of discrete "stop the world" actions and more as a continuous loop. As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality. It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be.

CorrectHorseBat 4y ago
>As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality. That's a job for the testsuite then, I don't want my version control system to require language specific knowledge. It is also a very hard problem if you want to do it 100% correct. Impossible I would say. >It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be. I really don't understand how that could work or why you even want it in the first place. It sounds like a nightmare to me. I want to be able to make some local changes, stage them, maybe commit and rebase and finally review and push. For very simple documents live editing works great, but for bigger ones it sucks. I would love to see documents move to the git workflow. Imagine a Word document or an Excel table with an automatically generated version history table from commits, that would be great.