5 ms·

Why? Excel is incredibly powerful. Most no-code platforms can't do much compared to Excel.

fragmede 3y ago
Because it doesn't version control well, it's hard to introspect, the data and code are all jumbled together. Emailing xls files around is functional, sure, but the software developer in me dies a little bit every time I do_final(1).xls I don't know that a hypothetical no-code tool does any better at any of those, but Excel, powerful as it is, has some real issues.
- lupire 3y ago
  Excel has had version control for years, via 365. https://support.microsoft.com/en-us/office/view-previous-versions-of-office-files-5c1e076f-a9c9-41b8-8ace-f77b9642e2c2 https://support.microsoft.com/en-us/office/view-previous-ver...
  - isbvhodnvemrwvn 3y ago
    That's backup with point in time restore rather than version control. It can't track semantic meaning of changes.
  - fragmede 3y ago
    That version control isn't very good. It dumps me into a snapshot of that time, of both the data and the formulae together. Useful to see how things were 2 years ago, using 2 year old data, but in order to take that data, but use the modern formulae against it is a chore of hoping I get the copy and paste right. There is also no documentation on why those formulae were chosen. Compared to git log -p, to see the changes in all the places there are instead of hoping I click on the right cell and catch all the changes.
- WorldMaker 3y ago
  XLSX are zip packages. It can be "fun" to version control the contents of the XLSX rather than that binary zip. Most of the data inside is just XML and with a good (stable) XML autoformatter you can even see some nice diffs between versions of an XLSX file. A long time ago for interesting reasons of my own (including the fact that I was using darcs at the time and diff/patch-size especially of binary files was directly a performance issue) I wrote a tool called musdex to automate that workflow as (in git terms) pre-commit/post-checkout/post-merge hooks. I offer no warranties for anyone wild enough to use a tool like that in production Excel workflows, but it's a "fun" thing to try.
  - Izkata 3y ago
    In actual git you'd do this with a .gitattributes file, defining a specific executable to do the diff. The docs show it being done with a docx (by converting to text) and a png (using its metadata): https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...
    - WorldMaker 3y ago
      I've used musdex in "actual git" with the aforementioned hooks. It works pretty well. There are some advantage to the chosen hooks approach rather than a git attributes-based approach especially that it is more "portable": GitHub doesn't need to have musdex installed to view "musdexed" repositories and you get the nicer merge/diff behaviors from standard diff/merge in PRs and commit views and everywhere. Also, while it is much less of a performance boost compared to darcs, git still benefits in some cases of pack file delta compression/optimization due to smaller differences in "musdexed" text/XML files rather than binary containers. I have one public example of this on my GitHub that comes to mind, but it's a particularly weird one because it uses a musdex plugin to extract/combine an already non-binary format. (In this case it was an Inform 7 story.ni file that I just preferred to source control as lots of smaller, column-wrapped "chapter" files rather than one long "book" file of run-on paragraphs. GitHub's cool modern code browser hasn't been taught how to do jump to section for Inform 7 story.ni files, so it is nice being able to browse it as a file tree instead. Similar it's nice to see commit diffs broken down by chapter. I can't install my own Inform 7 plugin to GitHub's website, but I can certainly reshape my repo with a tool like musdex.)
ebiester 3y ago
What they lose is a long history and community knowledge of hacks. What they gain is data integrity, consistency, and concurrency. We need to think about a tool that can do those with the same ease as Excel (Or Access). If we can't do that, it's because we need to make these tools better.

Because it doesn't version control well, it's hard to introspect, the data and code are all jumbled together. Emailing xls files around is functional, sure, but the software developer in me dies a little bit every time I do_final(1).xls I don't know that a hypothetical no-code tool does any better at any of those, but Excel, powerful as it is, has some real issues.

lupire 3y ago
Excel has had version control for years, via 365. https://support.microsoft.com/en-us/office/view-previous-versions-of-office-files-5c1e076f-a9c9-41b8-8ace-f77b9642e2c2 https://support.microsoft.com/en-us/office/view-previous-ver...
- isbvhodnvemrwvn 3y ago
  That's backup with point in time restore rather than version control. It can't track semantic meaning of changes.
- fragmede 3y ago
  That version control isn't very good. It dumps me into a snapshot of that time, of both the data and the formulae together. Useful to see how things were 2 years ago, using 2 year old data, but in order to take that data, but use the modern formulae against it is a chore of hoping I get the copy and paste right. There is also no documentation on why those formulae were chosen. Compared to git log -p, to see the changes in all the places there are instead of hoping I click on the right cell and catch all the changes.
WorldMaker 3y ago
XLSX are zip packages. It can be "fun" to version control the contents of the XLSX rather than that binary zip. Most of the data inside is just XML and with a good (stable) XML autoformatter you can even see some nice diffs between versions of an XLSX file. A long time ago for interesting reasons of my own (including the fact that I was using darcs at the time and diff/patch-size especially of binary files was directly a performance issue) I wrote a tool called musdex to automate that workflow as (in git terms) pre-commit/post-checkout/post-merge hooks. I offer no warranties for anyone wild enough to use a tool like that in production Excel workflows, but it's a "fun" thing to try.
- Izkata 3y ago
  In actual git you'd do this with a .gitattributes file, defining a specific executable to do the diff. The docs show it being done with a docx (by converting to text) and a png (using its metadata): https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...
  - WorldMaker 3y ago
    I've used musdex in "actual git" with the aforementioned hooks. It works pretty well. There are some advantage to the chosen hooks approach rather than a git attributes-based approach especially that it is more "portable": GitHub doesn't need to have musdex installed to view "musdexed" repositories and you get the nicer merge/diff behaviors from standard diff/merge in PRs and commit views and everywhere. Also, while it is much less of a performance boost compared to darcs, git still benefits in some cases of pack file delta compression/optimization due to smaller differences in "musdexed" text/XML files rather than binary containers. I have one public example of this on my GitHub that comes to mind, but it's a particularly weird one because it uses a musdex plugin to extract/combine an already non-binary format. (In this case it was an Inform 7 story.ni file that I just preferred to source control as lots of smaller, column-wrapped "chapter" files rather than one long "book" file of run-on paragraphs. GitHub's cool modern code browser hasn't been taught how to do jump to section for Inform 7 story.ni files, so it is nice being able to browse it as a file tree instead. Similar it's nice to see commit diffs broken down by chapter. I can't install my own Inform 7 plugin to GitHub's website, but I can certainly reshape my repo with a tool like musdex.)

ebiester 3y ago

What they lose is a long history and community knowledge of hacks. What they gain is data integrity, consistency, and concurrency. We need to think about a tool that can do those with the same ease as Excel (Or Access). If we can't do that, it's because we need to make these tools better.