5 ms·
If you’re going to store the source in a canonical format and unpack that to suit each developer… why should the canonical format just be regular source code?
by danielheath 1y ago
If you’re going to store the source in a canonical format and unpack that to suit each developer… why should the canonical format just be regular source code?
All the same tools can exist with a text backend, and you get grep/sed support for free too!
- giveita 1y agoMy grep may not work on your settings for the same code. This becomes an issue with say CI where maybe I add a gate to check something with grep. But whose format do I assume? My local (that I used to test it locally) or the canonical (which means I need to switch local format to test it)?
- treadmill 1y agoYou're misunderstanding the idea I think. You would use the format on disk for the grep. "Your format" only exists displayed in your editor.
- giveita 1y agoAha
- brabel 1y agoYou really rely on grep on CI? How fragile is that ?! This is a good argument for storing non-text. Grepping code is laughably unreliable. The only way to write things like that reliably is by actually parsing the code and working in its AST. Working in text is like writing code in a completely untyped language. It can be done, but it’s beyond stupid for anything where accuracy matters.
- psychoslave 1y agoThat’s seems like a genious remark actually. If you store the abstract objects and have the mechanism to transform to whatever the desired output form is, it’s almost trivial to expose a version as files and text rendering for tools that are thus oriented, isn’t it?
- danielheath 1y agoOriginally my fathers idea from back in the 90s to create a language with a whole suite of syntactic representations to suit your preferences. Want it to look like C? Lisp? Pascal? Why not!
- psychoslave 1y agoDo you have more references about what your fathers did back then?