15 ms·

Formatting code should be unnecessary

• kelseyfrog 1y ago
  The tradeoff here is not being able to use a universal set of tooling to interact with source files. Anything but text makes grep, diff, sed, and version control less effective. You end up locked into specialized tools, formats, or IDE extensions, while the Unix philosophy thrives on composability with plain text. There's a scissor that cuts through the formatting debate: If initial space width was configurable in their editor of choice, would those who prefer tabs have any other arguments?
  • Avshalom 1y ago
    The entire OS was built around these source files. the unix philosophy on the other hand only "thrives" if every other tool is designed around (and contains code to parse) "plain text"
    • lmm 1y ago
      > The entire OS was built around these source files. And how did that work out for them? This seems like one of the many cases where unix won out by being a lowest common denominator. Every platform can handle plain text.
      • aleph_minus_one 1y ago
        > This seems like one of the many cases where unix won out by being a lowest common denominator. The lowest common denominator rather is binary blobs. :-)
        • thfuran 1y ago
          The conversion of which to text and back has historically proven rather fraught.
      • account42 1y ago
        Not all platforms come with powerful text handling tools out of the box - or at least they didn't used to until Unix-based systems forced them to catch up.
  • jsharpe 1y ago
    Exactly. This idea comes up time and time again, but the cost/benefit just doesn't make sense at all. You're adding an unbelievable amount of complex tooling just to avoid running a simple formatter. The goal of having every developer viewing the code with their own preferences just isn't that important. On every team I've been on, we just use a standard style guide, enforced by formatter, and while not everyone agrees with every rule, it just doesn't matter. You get used to it. Arguing and obsessing about code formatting is simply useless bikeshedding.
    • scubbo 1y ago
      I disagree with almost every choice made by the Go language designers, but `Gofmt's style is no one's favorite, yet gofmt is everyone's favorite` is solid. Pick a not-unreasonable standard, enforce it, and move on to more important things.
      • spyspy 1y ago
        My only complaint about gofmt is that it’s not even stricter about some things.
        • duskwuff 1y ago
          Good news: there are tools like https://github.com/mvdan/gofumpt https://github.com/mvdan/gofumpt which fork gofmt and enforce stricter rules (while remaining invariant under gofmt).
    • rbits 1y ago
      Yeah it would probably be a waste of time. It's a nice idea to dream about though. It would be nice to be able to look at some C# code and not have opening curly brackets on a separate line.
      • mdaniel 1y ago
        I say this fully cognizant of the thread in which it's posted, but these people are sick https://astyle.sourceforge.net/astyle.html#_style=whitesmith https://astyle.sourceforge.net/astyle.html#_style=whitesmith And then someone said: oh yeah? Hold my beer https://astyle.sourceforge.net/astyle.html#_style=pico https://astyle.sourceforge.net/astyle.html#_style=pico
  • cowsandmilk 1y ago
    How is diff less effective? I see the diff in the formatting I prefer? With sed, I can project the source into a formatting most convenient for what I’m trying to do with sed. And I have no idea what you’re on about version control. It ruins sending patch files that require a line number around, but most places don’t do that any more. What I would be curious on is tracing from errors back to the source code. Nearly every language I’ve used prints line number and offset on the line for the error. How that worked in the Diana world would be interesting to learn.
    • sublinear 1y ago
      You'd have to run diff and sed before the formatter which is harder for everyone.
      • peanball 1y ago
        I can only recommend difftastic[1], which is a language aware diff. Independent of linter that shows the logical diff, not an assortment of characters or lines that changed. [1]: https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic
  • accelbred 1y ago
    What if the common intermediate encoding is text, not binary? Then grep/diff/sed all still work. If we had a formatting tool that operated solely on AST, checked in code could be in a canonical form for a given AST. Editors could then parse the AST and display the source with a different formatting of the users choice, and convert to canonical form when writing the file to disk.
    • sublinear 1y ago
      Nobody wants to have to run their own formatter rules in reverse in their head just to know what to grep for. That defeats the point of formatting at all.
      • pwdisswordfishz 1y ago
        That's why you grep for a syntactic structure, not undifferentiated text.
        • michaelmrose 1y ago
          Which grep doesn't do and you need to either use a new different tool or more likely several for little real benefit
          • jitl 1y ago
            comby is fantastic, give it a shot. It’s saved me huge amounts of time.
          • hnlmorg 1y ago
            grep is half a century old now. If we can’t progress our ecosystem because we are reliant on one very specific 50+ year old line parser, then that says more about the inflexibility of the industry to move forward than it does about the “new” ideas being presented.
            • komali2 1y ago
  • charcircuit 1y ago
    In practice how many tools do you really need to handle the custom format? Probably single digits and they could all use a common library to handle the formatting aspect of things.
  • bee_rider 1y ago
    Is it possible converted from the DIANA ir back to something that looks like source code? Then the result of the conversion backward could be grepped, etc…
    • teo_zero 1y ago
      From TFA: > Everyone had their own pretty-printing settings for viewing [DIANA] however they wanted.
      • bee_rider 1y ago
        > Back when he was working on Ada, they didn't store text sources at all — they used an IR called DIANA. Everyone had their own pretty-printing settings for viewing it however they wanted. I’m still confused because the specifically call the IR DIANA, and they talk about viewing the IR. It isn’t clear to me if the IR is more like a bytecode or something, or more like just the original source code with a little processing done to it. They also have a quote, > Grady Booch summarizes it well: R1000 was effectively a DIANA machine. We didn't store source code: source code was simply a pretty-printing of the DIANA tree. So maybe the other visualizations they could do by transforming the IR were so nice that nobody even cared to look at the original ADA that they’d written to generate it?
        • brabel 1y ago
          I imagine it’s like storing JVM bytecode, ie class files instead of Java files. So when you open it up the editor decompiles it , like IntelliJ does if you try to open a class file, but then it also applies your own style, like from .editorconfig, on the code it shows. It’s a really good idea and I can’t believe people here are complaining that it’s bad because they can’t use grep! But that’s a good thing!! Who the hell is grepping code as if code had no structure and that’s the best you can do? So you also grep JSON instead of using jq? Just don’t!
  • froh 1y ago
    yes, contemporary editors and tools like treesitter have decided this debate in favor of plain text file representation, exactly for the reasons you give: universal accessibility by general purpose tools. xslt was a Diana like pre-parsed representation of dsssl. oh how I miss dsssl (a scheme based sgml transformation language) but no. dsssl was a lisp! with hygienic macros! "ikes" they went and invented XSLT. the "logic" escapes me to this day. no. plain text it is. human readable. and grep/sed/diff able.
  • 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 ago
      My 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 ago
        You'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 ago
          Aha
      • brabel 1y ago
        You 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 ago
      That’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?
  • eviks 1y ago
    > If initial space width was configurable in their editor of choice, would those who prefer tabs have any other arguments? Yes, of course, because tab width is * dynamically* flexible, so initial space width isn't enough
    • pasc1878 1y ago
      Yes because if you want to deindent with tabs it is just delete one character whilst spaces requires you top delete x characters where x is the number of spaces you indent by.
      • eviks 1y ago
        For "clean-fixed-width" unambiguous indent (eg, at the beginning of lines) you can make delete also delete X=indent_width spaces. But for "dirty-width" indents, eg, after some text that can vary in size (proportional fonts or some special chars even in fixed fonts) you can't align with spaces while a tab width can be auto-adjusted to match the other line
  • MyOutfitIsVague 1y ago
    The way I envision this working is with something like git filters. Checking out from version control converts it all into text in your preferred formatting, which you then work with as expected. Staging it converts it into the stored representation. In git, this would be done with smudge and clean filters, like how git LFS works. You'd also have viewers for forges and the like that are built to interpret all the stored representations as needed. You still work with text, the text just isn't the canonical stored representation. You get diffs to resolve only when structure is changed. You get most of the same benefit with a pre-commit linter hook, though.
    • bapak 1y ago
      This is it, unfortunately git is "too dumb" for this. In order to merge code, it would have to either understand the AST. What happens when you stage the line `} else return {`? git doesn't allow to stage specific AST nodes. It would also mean that you can't stage partial code (that produces syntax errors)
      • Hendrikto 1y ago
        Smudge and clean filters work on text, git would not need to change at all. You would still store text, and still check out text, just transformed text. You could still check in anything you want, including partial code, syntax errors, or any other arbitrary text. Diffs would work the same way they do now.
      • zokier 1y ago
        Git can use arbitrary merge (and diff) tools. Something like https://mergiraf.org/introduction.html https://mergiraf.org/introduction.html works with git and gets you ast aware merging. Do not underestimate gits flexibility.
    • account42 1y ago
      Please no, git trying to automatically "correct" \n vs \r\n line endings is already horrible enough. At least you can turn that off.
    • 1y ago
  • rendaw 1y ago
    Grep, diff, sed, and line-based non-semantic merge are all terrible tools for manipulating code... rather than dig ourselves in either further with those maybe a reason to come up with something better would be good.
  • aleph_minus_one 1y ago
    > Anything but text makes grep, diff, sed, and version control less effective. Perhaps this is rather a design mistake in how UNIX handles things and is so focused on text.
  • gr__or 1y ago
    Text surely is a hill, but I believe it's a local one, we got stuck on due to our short-sighted inability to go into a valley for a few miles until we find the (projectional) mountain. All of your examples work better for code with structural knowledge: - grep: symbol search (I use it about 100x as often as a text grep) or https://github.com/ast-grep/ast-grep https://github.com/ast-grep/ast-grep - diff: https://semanticdiff.com https://semanticdiff.com (and others), i.e.: hide noisy syntax only changes, attempt to capture moved code. I say attempt, because with projectional programming we could have a more expressive notion of code being moved - sed: https://npmjs.com/package/@codemod/cli https://npmjs.com/package/@codemod/cli - version control: I'd look towards languages like Unison to see what funky things we could do here, especially for libraries. A general example: no conflicts due to non-semantic changes (re-orderings, irrelevant whitespaces, etc.)
    • zokier 1y ago
      But as the tools you link demonstrate, having "text" as the on-disk format does not preclude AST based (or even smarter) tools. So there is little benefit in having non-text format. Ultimately it's all just bytes on disk
      • gr__or 1y ago
        Even that is not without its cost. Most of these tools are written in different languages, which all have to maintain their own parsers, which have to keep up with language changes. And there are abilities we lose completely by making text the source of truth, like a reliable version control for "this function moved to a new file".
        • theamk 1y ago
          At least the parsers are optional now - you can still grep, diff, etc.. even if your tools have no idea about language's semantics. But if you store ASTs, you _have_ to have the support of each of the language for each of the tools (because each language has its own AST). This basically means a major chicken-and-egg problem - a new language won't be compatible with any of the tools, so the adoption will be very low until the editor, diff, sed etc.. are all updated.. and those tools won't be updated until the language is popular. And you still don't get any advantages over text! For example, if you really cared about "this function moved to new file" functionality, you could have unique id after each function ("def myfunc{f8fa2bdd}..."), and insert/hide them in your editor. This way the IDE can show nice definition, but grep/git etc.. still work but with extra noise. In fact, I bet that any technology that people claim requires non-readable AST files, can be implemented as text for many extra upsides and no major downsides (with the obvious exception of truly graphical things - naive diffs on auto-generated images, graphs or schematics files are not going to be very useful, no matter what kind of text format is used) Want to have each person see it's own formatting style? Reformat to person's style on load and format back to project style on save. Modern formatters are so fast, people won't even notice this. Want fast semantic search? Maintain the binary cache files, but use text as source-of-truth. Want better diff output? Same deal, parse and cache. Want to have no files, but instead have function list and edit each one directly, a la Smalltalk? Maintain files transparently with text code - maybe one file per function, or one file per class, or one per project... The reason people keep source code as text as it's really a global maximum. The non-text format gives you a modest speedup, but at the expense of imposing incredible version compatibility pain.
  • Ygg2 1y ago
    > would those who prefer tabs have any other arguments? Yes. Because Yaml exists. And mixing tabs and spaces is horrible in it. And the rules are very finnicky. Optimal tab usage is emit 2-4 spaces.
• shmerl 1y ago
  You can't easily search / grep etc. an IR, unless you use some kind of reverse translator. Readable source files have their benefits in being simple in that sense.
  • marssaxman 1y ago
    Imagine having to write a new diff tool for each language!
    • kesor 1y ago
      You don't need a special grep for every language, you just need a tool that translates the mini version into the formatted version and back. Then you chain the tools, just like anything else in UNIX.
      • marssaxman 1y ago
        Seems reasonable. Since you're likely to perform this translation more than once for any given file, it seems like it would be practical to cache the translated output, perhaps as a file on disk.
  • eviks 1y ago
    > unless you use some kind of reverse translator Would a few decades help in universally having such a translator in all the tools?
    • account42 1y ago
      In all the tools? No, you'd need an infinite amount of time for that.
      • eviks 1y ago
        The tools didn't require an infinite amount of time to write, why would it take infinity to change a format??? (but no not all the tools, just all the ones that are used)
• banashark 1y ago
  Interesting read. I’ve often wondered why the projection we see needs to be the same as the stored artifact. Even something like a git diff should be viewable via a projection of the source IR. With things like treesitter and the like, I sometimes daydream about what an efficient and effective HCI for an AST or IR would look like. Things like f#s ordered compilation often make code reviews more simple for me, but that’s because a piece of the intermediate form (dependency order) is exposed to me as a first class item. I find it much more simple to reason about compared to small changes in code with more lax ordering requirements, where I often find myself jumping up and down and back and forth in a diff and all the related interfaces and abstract classes and implementations to understand what effect the delta is having on the program as a whole.
• lordnacho 1y ago
  Aren't most projects these days written in a mix of languages, most of them text? You'd have to get them to change to use the same tools we currently use, or else you'd have to use special tools. The beauty of the modern stack is the base tools are near universal. If you want everyone to see their own preference of format, either write a script or get AI to format it for you.
• ChrisMarshallNY 1y ago
  I've heard that Google works [sort of] that way (don't know, myself). They have a lot of tools that allow devs to use what formatting they want, and it's made standard, during checkin. I heard this, many years ago, when we used Perforce. The Perforce consultant that we dealt with, told us this, as an example of triggers. Back then, I was told that Google was a big Perforce shop (maybe just a part of Google. I dunno). I have heard that this was one of the goals of developing IDLs. I think the vision was, that you could have a dozen different programmers, working in multiple languages (for example, C for the drivers, Haskell for the engine, and Lua for the UI). They would be converted to a common IDL, when submitted to configuration management, and then extracted from that, when the user looks at it. I can't see that working, but a lot of stuff that I used to think was crazy, has happened, so, who knows?
  • __loam 1y ago
    Go was designed at Google with a built in style checker to explicitly address this and prevent bikeshedding.
  • yojo 1y ago
    I can confirm that Google was using Perforce for version control extensively, at least through 2008. I think it was somehow customized, but I definitely have lingering muscle memory around “p4 sync” and “p4 submit”. I was on an internal tools team doing distinctly unsexy LAMP-stack work, but all the documentation I ever saw talked about perforce/p4.
• lisper 1y ago
  It never ceases to amaze me how many times people can essentially re-invent S-expressions without realizing that's what they are doing.
  • mdaniel 1y ago
    Wait until that Bablr user shows up to these threads, and then you'll really have to start drinking
    • conartist6 1y ago
      Wow I am thoroughly honored. You are probably the first person ever who isn't me to bring it up in a thread. I had never heard of DIANA but I love old ideas being new again. (Plus you made me laugh)
  • benrutter 1y ago
    Scanning the comments waiting for a lisper to comment and found one! I guess lisp still has whitespace? That seems like the only meaningful way it isn't already just what the post is describing.
    • Jach 1y ago
      In actual Common Lisp development, code is stored in text files and edited and diffed as text in source controlled repositories. Once code is evaluated by an implementation, it's a different story, but before that there are many formatting options. It's mostly around where to put line breaks, whitespace, and parens, but still. The other day I wrote this simple function: (defun check-password-against-hash (password hash) (handler-case (bcrypt:password= password hash) (error () nil))) There's already multiple choices on formatting (and naming, and other things) just from this sample. In theory a system could be made where this level of code isn't what's actually stored and is just a reverse pretty-print-with-my-preferences version of the code, as the post mentions. SBCL compiles my function when I enter it, I can ask SBCL to describe it back to me: * (describe #'check-password-against-hash) #<FUNCTION CHECK-PASSWORD-AGAINST-HASH> [compiled function] Lambda-list: (PASSWORD HASH) Derived type: (FUNCTION (T T) *) Source form: (LAMBDA (PASSWORD HASH) (BLOCK CHECK-PASSWORD-AGAINST-HASH (HANDLER-CASE (CL-BCRYPT:PASSWORD= PASSWORD HASH) (ERROR NIL NIL)))) I can also ask SBCL to show me the disassembly, perhaps again in theory a system could be made where you can get and edit text at that level of abstraction before putting it back in. * (disassemble #'check-password-against-hash) ; disassembly for CHECK-PASSWORD-AGAINST-HASH ; Size: 308 bytes. Origin: #xB8018AA278 ; CHECK-PASSWORD-AGAINST-HASH ; 278: 498B4510 MOV RAX, [R13+16] ; thread.binding-stack-pointer ; 27C: 488945F8 MOV [RBP-8], RAX ; 280: 488965D8 MOV [RBP-40], RSP ; 284: 488D45B0 LEA RAX, [RBP-80] ; 288: 4D8B7520 MOV R14, [R13+32] ; thread.current-unwind-protect-block ; 28C: 4C8930 MOV [RAX], R14 ; ... and so on .... (SBCL does actually let you modify the compiled code directly if you felt the urge to do such a thing. You just get a pointer to the given origin address and offset and write away.) But just going back to the Lisp source form, it's close enough that you could recover the original and format it a few different ways depending on different preferences. e.g. someone might prefer the first expression given to handler-case to be on the same line instead of a new line like I did. But to such a person, is that preference universal, or does it depend on the specific expressions involved? There are other not strictly formatting preferences at play here too, like the use of "cl-bcrypt" vs "bcrypt" as package name, or one could arrange to have no explicit package name at all. My own preferences on both matters are context-sensitive. The closest universal preference I have around this general topic is that I really hate enforced format tools even if they bent to my specific desires 100% of the time. I'd say the closest modern renditions of what the post is talking about are expressed by node editors. Unreal's Blueprints or Blender's shader editor are two examples, ETL tools are another. But people tend to work at the node level (and may have formatting arguments about the node layout) rather than a pretty-printed text representation of the same data. I think in the ETL world it's perhaps more common to go under the hood a little and edit some text representation, which may be an XML file (and XML can be pretty-printed for many different preferences) or a series of SQL statements or something CSV or INI like... whether or not that text is a 'canonical' representation or a projection would depend on the tool.
• preommr 1y ago
  Others have already mentioned how why this is a bad idea (e.g. common plaintext tools don't work, added complexity, etc.) But I'll also mention that this pretty much already exists. You can have whitespace options for git. I also imagine there's some setup using hooks that uses one formatter locally, and another for remote. Also, the common IR already exists - it's just the AST. It was "solved" back in the day when people were throwing whatever they could to the wall to see what sticks since it was all so new. With the benfit of hindsight, I think we can say that it's not that good of an idea.
• cnnlives83 1y ago
  It basically is, unless you’re in a whitespace-Nazi language like Python (no offense!). It doesn’t get much less formatted than Minified JavaScript, except maybe Perl or Brainfuck.
  • kesor 1y ago
    Minified JS often comes with mangling the names of functions, variables, etc... Formatters and prettifiers lack the ability to bring back the original names and meaning.
• crq-yml 1y ago
  I think the problem can be defined equally as: we can't invest in something more abstract than "plain text" at this time. When we try, it gets downgraded to a plain text projection of the syntax. The plain text encoding itself exists in a process of incremental, path-dependent development from Morse Code signals to Unicode resulting in a "Gigantic Lookup Table" (GLUT, my coining) approach to symbolic comprehension. The assumption is useful - lots of features can "just work" by knowing that a particular bit pattern is always a particular symbol. If we push up the abstraction level, we get a different set of symbols that are better suited to the app, but not equivalent GLUT tooling. Instead we usually get parsing of plain text as a transport. For example, CSV parsing. It is sloppy; it is also good enough. Edit: XML is also a key example. It goes out of its way to respect the text transport approach. There are dedicated XML editors. But people want to edit it as plain text and they can't quite get there because funny-business with character encodings gets in the way, adding a bunch of ampersands and semicolons onto the symbols they want to edit. Thus we have ended up with "the CSV of hypertext documents", Markdown.
• hackerbrother 1y ago
  Along these lines, Go eliminates many formatting decisions at the syntax level. E.g., func main() { fmt.Println("HELLOWORLD") } is not just non-standard formatting, but illegal Go syntax. Similarly, extra parentheses around if clauses are not allowed.
  • TheDong 1y ago
    > Similarly, extra parentheses around if clauses are not allowed. However 'if (x) == (1) {}' is totally fine with the formatter. As is an assignment of '(x) = (y)'. It's actively annoying too because like, extra parenthesis often have important meaning. For example, consider the following code: if (x.isFoo() || x.isBar()) /* && x.isBaz() */ { /* code */ } In that case, the code is obviously temporarily commented out, but go's formatting will make it so that if you comment it out like that, fmt, and then uncomment it and forget to re-add the parens, you get shot in the foot. I've hit that far more times than it's uhh... I dunno, I guess removed parenthesis I didn't want? I don't write them if I don't want them.
    • lsaferite 1y ago
      go is generally hostile to temporarily commenting out code. The if syntax issue you call out is just one aspect. Another is the inability to have unused variables.
    • lsaferite 1y ago
      FWIW, in that scenario, for the reasons you've called out, I would normally dupe the if line and comment the original one for reference. Mind you, none of that would ever get committed, but for a temp local change it's fair game.
• davetron5000 1y ago
  There’s also a typography element to formatting source code. The notion that all code formatting is mere personal preference isn’t true. Formatting code a certain way can help to communicate meaning and structure. This is lost when the minimal tokens are serialized and re-constituted using an automated tool. https://naildrivin5.com/blog/2013/05/17/source-code-typography.html https://naildrivin5.com/blog/2013/05/17/source-code-typograp...
  • jauntywundrkind 1y ago
    I'm pretty unconvinced by the examples. > Some of us even align other parts of our code, such repeated inline comments > Now, the arguments block forms a table of three columns. The modifiers make up the first column, the data types are aligned in the second column, and the names are in the third column These feel like pretty trivial routines that can be encompassed by code formatting. We can contrive more extreme examples, like the for loop, but super custom formatting ("typesetting") like that has always made me feel awkward, feels like it givesicemse for people to use all manners of arbitrary formatting. The author has some intent, but when you run into an inconsistent code based with lots of things going on, the variance doesn't feel informative or helpful: it sucks and it's a drain. What's stored is perhaps more minimal, some kind of reference encoding, maybe prettier-ifies for js. The meat of this article to me is that it shouldn't matter: the IDE should let you view and edit as you like: > Everyone had their own pretty-printing settings for viewing it however they wanted.
  • frizlab 1y ago
    Yes! I’m always appalled that people cannot see that.
  • pwdisswordfishz 1y ago
    > A C argument declaration is made up of modifiers (register, const), a data type (char *), and a name (from). Now explain a declaration like "char *argv[]"... > We’ve also re-set the data type such that there is no space between char and * - the data type of both of these variables is “pointer to char”, so it makes more sense to put the space before the argument name, not in the middle the data type’s name (update: it should be pointed out that this only makes sense for a single declaration. A construct like char* a, b will create a pointer to char, a, and a regular char, b). Ah, yes, the delusional C++ formatting style. At least it's nice that the update provides the explanation why it should be avoided.
• bertil 1y ago
  That’s essentially what black has done with Python, though.
  • dubya 1y ago
    I want to like Black (or rather, uv format), but the mandatory trailing commas weird me out, especially in function definitions. It always looks like an error to me.
    • thewisenerd 1y ago
      this is so future 'git diff's when adding new parameters don't look bad i wonder how many default formatting decisions are made this way (including go fmt, etc)
      • dubya 1y ago
        I've seen the reason, I just don't find it convincing. I would like to omit these commas, but also use the formatter sometimes, but that's not really an option. It's frustrating since 'uv format' will omit them for older python versions, so the logic is there. Something between "everything fits on one short line" and "every argument gets its own line" would be nice too. Spreading a function definition or call across ten lines when it would fit on two or three doesn't feel like an automatic win.
• yeasku 1y ago
  Kind of a stupid take if you ever plan on sharing your code or using git.
  • kesor 1y ago
    Is it? When every developer has an IDE that can easily format the code in whichever the way they prefer, and minify it back just before pushing a commit.
    • MaxLeiter 1y ago
      No reason websites couldn’t let you choose how to view it like editors, either
    • yeasku 1y ago
      The world is not javascript.
• lxe 1y ago
  > you could view the source however you wanted. Spaces vs. tabs didn't matter because neither affects the semantics and the editor on the system let you modify the program tree directly (known today as projectional editing). But formatting still doesn't matter. Outside of whitespace-dependent languages, formatting is a subjective thing -- it's a people concern, not a computer concern. I can store my JavaScript as AST if I want to.
  • kmoser 1y ago
    There are annoying edge cases where formatting does matter, such as whitespace around HTML text nodes, e.g.: <span>foo</span> vs: <span> foo </span>
    • grumbelbart2 1y ago
      Sure, but the same goes for verbatim strings, or leading whitespaces in python. "Code formatting" questions usually only concern themself with those degrees of freedom that do not alter the semantic meaning of the code.
      • kmoser 1y ago
        Agreed, but my experience is that many formatters will try to "help" by formatting non-code, thereby breaking something.
• PaulKeeble 1y ago
  In theory we could have an IDE apply a reformatting to any piece of code we looked at and formatted any changes back to the standard for the code base on updates. One of the things I dislike is that sometimes autoformatting does a poor job and looses some information that manually formatting provides but honestly in go fmt is mostly fine it just works. All of this seems doable, I just think for the most part we don't care very much about our preferences, it has very little impact on readability. Its definitely doable however we could view the code however we most wanted it and have it stored in a different formatting. Might not be 100% round trip stable but it probably doesn't matter. There is always better where the defaults can be overridden and formatting forced and we only format new and changed lines to reduce potential instability but again go fmt doesn't really suffer from this so its possible to make things pretty reliable. Its simple really, there is a default formatting and the code is stored that way and we can then have our view of choice reformat the code as we want it, when its stored its stored in the default.
• kesor 1y ago
  This is how Chrome Dev Tools shows source code. The original is often minified or in whatever format the author left it. And when you check the "pretty" checkbox in dev tools, it shows up using whichever format Chrome developers decided it should look like.
• jmward01 1y ago
  I have gotten into discussions with people about linters and code formatting standards in general and I always liken it to a work desk. If my company decided that every work desk had to be 100% generic and that every day if I put any adjustment, even to the seat height, on that desk they would reset it, I would probably think that place was hostile. Even if I could 'auto format' it back to something close every time I stepped up to the desk I would be pretty unhappy. It just wouldn't feel like mine and eventually I would be beaten into whatever style, which wasn't my own, the code came out of the repo as. Basically, linters are evil. They only work for the person that set them up. Leave code format up to the primary owner of the file. It is pretty rare that code has more than one person that does 95% of the edits on a file so let them own the formatting. In the rare case where there are shared files with shared edits then it is ok to mandate some sort of enforced format but those are so rare that it generally isn't worth discussing. The proposed approach here ignores all the messy non-standard stuff that happens because of the margins or the rules that are very hard to build in when codifying personal coding style. Let me have my messy desk and I'll let you have yours.
• __MatrixMan__ 1y ago
  Unison doesn't move the formatting choices further than the machine on which the code was written. The codebase only contains the AST. Its such a cool idea, though I haven't spent much time using it in anger, so its hard to say if its a useful idea.
  • wonger_ 1y ago
    Yeah, if any language has potential for AST source of truth instead of textual source of truth, it's Unison. I'm just waiting for a breakthrough project to show that it's ready for wider adoption. Leaving text-based tooling is a big ask. The principles behind Unison, for those who haven't read them yet: https://www.unison-lang.org/docs/the-big-idea/#richer-codebase-tools https://www.unison-lang.org/docs/the-big-idea/#richer-codeba... > Each Unison definition is identified by a hash of its syntax tree.
  • oftenwrong 1y ago
    Unison's immutable definitions also enable a bunch of compelling capabilities. No merge conflicts. Incremental everything: build, test, lint, distribution, rendering as formatted text, et cetera. Trivial to apply "hot" updates to running systems.
• laserbeam 1y ago
  Reminds me of dion systems. A few years ago a group of devs was working on a programming environment that feels very close to what DIANA is describing. The project is dead enough that they no longer own the TLD for the company. As far as I know, the only remnants of the project are youtube recordings of demos held at conferences.
• automatoney 1y ago
  I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.
  • jupp0r 1y ago
    I generally agree, but max line length being so high you have to horizontally scroll while reading code is very detrimental to productivity.
    • appellations 1y ago
      I forget there are people who don’t configure softwrap in their text editor. Some languages (java) really need the extra horizontal space if you can afford it and aren’t too hard to read when softwrapped.
    • forrestthewoods 1y ago
      Define high? I think 120 is pretty reasonable. Maybe even as high as 140. Log statements however I think have an effectively unbounded length. Nothing I hate more than a stupid linter turning a sprinkling of logs into 7 line monsters. cargo fmt is especially bad about this. It’s so bad.
      • skinner927 1y ago
        I still prefer 80. I won’t (publicly) scoff at 100 though. IMO 120 is reasonable for HTML and Java, but that’s about it. Sent from my 49” G9 Ultrawide.
        • forrestthewoods 1y ago
          Ugh. 80 is the worst. For C++ it’s entirely unreasonable. I definitely can not reconcile “linters make code easier to read” and “80 width is good”. Those are mutually exclusive imho. What I actually want from a linter is “120, unless the trailing bits aren’t interesting in which case 140+ is fine”. The ideal rule isn’t hard and fast! It’s not pure science. There’s an art to it.
• efortis 1y ago
  Projectional Editing can be done with text sources. Here’s an old video of JetBrains MPS rendering a table from code https://www.youtube.com/watch?v=XolJx4GfMmg&t=63s https://www.youtube.com/watch?v=XolJx4GfMmg&t=63s I’m hoping for an IDE able to render dictionaries as tables -- my wishlist doesn’t stop there. Currently, we have a glimpse of those features, such as code folding, inlay hints, or docstrings rendered as HTML: https://x.com/efortis/status/1922427544470438381 https://x.com/efortis/status/1922427544470438381
• TheAlchemist 1y ago
  I like that. We should have something like this for python. Black is great, but maybe it's just me since it aligns with how I like the code formatted. Would there be any downsides for python (or git ?) to define a standard way of formatting to save a valid file, and all the formatting necessary to read a file happens in the IDE showing the file ? That would very much fit with python ethos 'There should be one-- and preferably only one --obvious way to do it.'
  • benrutter 1y ago
    I think the downside would mainly be complexity. As soon as you do that, you have to develop what that intermediate representation is and how it gets stored. But moreover, you'd need to develop workarounds for the fact that all external code infrastructure (version control, editors, command line tools) is built for text. I can't see a crazy huge downside from a python point of view, but seems like a much bigger upside than flexible formatting would be needed to justify breaking from all of that stuff.
    • TheAlchemist 1y ago
      I was thinking just plain python - let's say Black formatted code is the default and we commit only that. Then on the visualization side, the IDE can format it for whatever we want. Actually, this could be a really easy feature for the IDE and could work already easily.
• chowells 1y ago
  I have to disagree with the premise. Formatting code is a critical communication channel. Well-formatted code should tell you: 1. The developer has enough experience to understand that formatting matters. 2. The developer has enough discipline to stick with their chosen formatting rules. 3. The developer has the taste necessary to choose good formatting rules. 4. The developer has the judgement necessary to identify when other concerns justify one-off violations of the rules. These are really important attributes for a developer to have. They affect every aspect of the code, not just formatting. Formatting is just a very quick proxy to measure those by. Unfortunately, things like autoformatting and linter rules are destroying the signal. Goodheart's law strikes again.
  • rho4 1y ago
    Not caring about formatting also signals to me that: - they have probably never worked on a codebase where files are edited by more than 1 person - they have never done any significant amount of merging between branches - they have never maintained a large codebase - they have never had to refactor a large codebase - they don't use diff/comparison tools to read the history of their codebase - they have never written any tooling for their codebase - they are not good team-players and/or only care about their own stuff
    • pure-orange 1y ago
      Did you not read the article?
  • babel_ 1y ago
    The blog entry is short and simple, perhaps consider reading it before knee-jerk reacting to the title, and then you might understand why "should" and "unnecessary" are operative in said title.
    • chowells 1y ago
      You've jumped to a fascinatingly false conclusion here. Is this the so-called death of media literacy? I replied to the ideas underlying the post rather than the words in it, and you think that means I didn't read it? To go through the details: The post explicitly complained about a linter enforcing style rules. It did not object to the presence of mechanically-enforced style rules. In fact, it glorified them implicitly by saying how great it would be if everything was formatted at presentation-time. This glorification is the exact thing I was criticizing. I think machine-enforced rules are bad because they destroy a communication channel that importantly has point 4 that I listed - when well-formatted code breaks its conventions, there must be a reason for it. That is important information that enforced presentation rules force to be put into another channel. And it's certainly true that other channels do convey this other information, but I find more value in having it conveyed in the presentation channel than I do in having that channel replaced by mechanistic formatting. This is the premise underlying the article that I object to. It is present so heavily in the subtext that if you pretend it's not, the post becomes incoherent. And FWIW, HN rules say not to accuse people of not having read the article. I think that rule is mostly there because someone can read the article and notice something you missed, and it's wiser to not post than it is to assume you absorbed 100% of the context of the post.
• pluto_modadic 1y ago
  my initial gut take from the title was "OH MY GOODNESS don't let {x} toxic developer who writes TERRIBLE code see this as justification". There are enough toxic bros who either 1. think this is unnecessary or 2. think it is perfectly solved. re: intermediate representation and projectional editing: yes, editors are now getting better at helping you refactor code (rename function in language XYZ is possible in language servers for IDEs, /no AI required, it works better when a human coded AST tool does it/) projectional editors aren't around /because the more complex parts of it are harder/ - BUT - I could definitely see more intelligent refactor tooltips written by humans. For example: in Rust, if I've been passing a pointer vs borrowing (or whatever), pattern A for most of my code, then pattern B and it complains, it would be useful to have a tooltip that goes "do you want to refactor all the other references/parameters to pattern B" instead of Rust's default "this function isn't using pattern A" borrow checker error.
• leipert 1y ago
  With git you could set up “smudge” filters to do your own formatting on checkout and “clean” formatting for the canonical formatting on staging files. https://git-scm.com/book/pt-br/v2/Customizing-Git-Git-Attributes#rfilters_a https://git-scm.com/book/pt-br/v2/Customizing-Git-Git-Attrib...
• hannasm 1y ago
  This article is barely a comment on some other situation; but I've been saying this to anyone who wants listen for years. There's nothing special about whitespace (unless you write python). Capitalization and a bunch of other stuff in your coding convention document are usually just signs that you have poor tooling and lack of skill. Give me a PR that satisfies the requirements and the appropriate test cases and i'll happily rewrite it to spaces only indented with curly braces on newlines and etc... as I see fit. The hard part is the first two tasks, you can train an intern to do the third
• perlgeek 1y ago
  > Back when he was working on Ada, they didn't store text sources at all — they used an IR called DIANA. Everyone had their own pretty-printing settings for viewing it however they wanted. What about comments? Were they part of the IR? (I agree with others that version control, grep etc. are also very important, and kind of a deal breaker).
  • lsaferite 1y ago
    I would fully expect any structured AST IR to also support comments across all aspects of the program. Ideally they would be better because by the nature of an AST IR, comment scope would be fully expressed structurally.
• komali2 1y ago
  Formatting code is unnecessary. You write it however you want, then run the lint fix command and prettier command, commit, and move on.
• _ZeD_ 1y ago
  good luck with that.. I didn't had a decent IDE capable of even implementing elastic tab stops... I expect people using hex editors to flip bytes directly on the binary blob saved on disk instead of using the appropriate tools to view the "source" files. btw: have a look at how much disdain was reserved for systemd and its pletora of binary blobs + custom tools (e.g. the journal stuff) ... and that was basically forced upon from the distributions
• Jean-Papoulos 1y ago
  So I need to run a tool to even be able to read the code. No thank you, if anything goes wrong your file is now garbage.
  • benrutter 1y ago
    In theory that's true of standard office document files too (.docx etc)? Don't think I've encountered too many issues of that actually happening though in the wild? I'm mainly just being pedantic to be honest, I realise my comment is just me essentially saying "what could possiblye go wrong?"
    • account42 1y ago
      Word documents absolutely do get messed up if you open it in a different office suite - or even a different enough version of the same suite.
  • IshKebab 1y ago
    Doesn't seem like a real risk - these files are all version controlled. The bigger problem is you now need custom tooling for your IDE, version control, diff & merge, code review, code hosting, etc. etc.
    • conartist6 1y ago
      You're spot-on. HTML and XML are similar textual embedding formats for documents which can contain arbitrary text. Neither is particularly good when the documents are syntax trees though. CSTML takes the design ideas that obviously work and adapts them to be natural for syntax trees, like this: https://gist.github.com/conartist6/75dc969b685bbf69c9fa9800cbfddb3f https://gist.github.com/conartist6/75dc969b685bbf69c9fa9800c.... The trees always store inside themselves the complete source code as the parser saw it, so there's little fear of not being able to recover the original, and they're quite human-readable unlike, say, docx files. My team and I are working on building out the VCS, diff and merge, review, hosting, grepping, blogging and other kinds of solutions necessary to make our format able to take over as a de-facto standard.
• pandemic_region 1y ago
  I wish for Java to have a built-in formatter just like Go has. Enough with these plugins and google-format and messy intelij settings.
• sirwhinesalot 1y ago
  I wrote an article saturday on visual programming which is very related to this, but my thinking is the opposite of this article. Raw text is amazing at smaller scales. The ability to apply a bunch of intermediate incorrect transformations to reach a valid destination is invaluable (like doing a bunch of hacky find/replace). Projectional editors like JetBrains MPS have tons of disadvantages vs text, and the few advantages don't make up for it. Formatting is a silly problem to have, but far beyond that why are we manipulating text files directly rather than editing a live program (ala Smalltalk). Text can just be the on-disk serialization format you never look at. (Raw text is still how you edit individual functions and methods in Smalltalk, there just isn't any actual text file on disk)
  • MaxLeiter 1y ago
    Drop a link!
    • sirwhinesalot 1y ago
      Sorry for the late reply, here you go: https://btmc.substack.com/p/thoughts-on-visual-programming https://btmc.substack.com/p/thoughts-on-visual-programming
  • whartung 1y ago
    My singular problem with visual programming is simply the amount of detail necessary in modern programming. Code is flat out complicated, with lots and lots and lots of steps, each with perhaps even more detail. And it's hard to do that efficiently with visual editors. Imagine a display with instead of thousands of lines of code, you have thousands of symbols. Or, the visual editors break things down in to components that are so small they do not convey the "big picture" well. It's a personal complaint with the way Smalltalk works. Lots of methods, small (ideally) snippets of code, all viewed in isolation. It's common (at least for me) to put related code together in the source file. It's useful to scan the whole file to get a feel for the flow of the code, and the system. Looking at isolated code, out of context, has always been a struggle for me. There's a reason my code is not sorted alphabetically by function name. Maybe if you organized code visually, that is, perhaps the upper left is the start up code, the lower right is some core math all collected together like beads in a pot. "All red ones go here, all the 1" ones go there". Granted I have not worked on such a tool or such a project. But the linear presentation of code as structured text has worked well for me, even when I bounce around between modules in the IDE.
• karel-3d 1y ago
  Formatting code is a typical bikeshed argument. Nobody can say a thing about the nuclear reactor, everyone has an opinion about the bike-shed.
• dark-star 1y ago
  In most languages (other than e.g. Python), formatting code is actually unnecessary...
• aleph_minus_one 1y ago
  Some (sometimes) desirable source code formatting cannot be deduced from the abstract syntax tree alone: Consider the following (pseudo-)code example: bar.glob = 1; bar.plu.a1 = 21; bar.plu.coza = fol; Should this code formatted this way? Or should it be formatted bar.glob = 1; bar.plu.a1 = 21; bar.plu.coza = fol; to emphasize that three assignments are done? Or should this code be formatted bar.glob = 1; bar.plu .a1 = 21; bar.plu .coza = fol; to bring make the "depth" of the structure variables more tabular so that you can immediately see by the tabular shape which "depth" a member variable has? We can go even further like bar.glob = 1; bar.plu.a1 = 21; bar.plu.coza = fol; which emphasizes that the author considers it to be very important that the reader can easily grasp the magnitudes of the numbers involved (which is why in Excel or LibreOffice Calc, numbers are right-aligned by default). Or combining this with making the depth "tabular": bar.glob = 1; bar.plu .a1 = 21; bar.plu .coza = fol; Each of these formattings emphasizes different aspects of the code that the author wants to emphasize. This information cannot be deduced from some abstract syntax tree alone. Rather, this needs additional information by the programmer in which sense the structure behind the code intended by the programmer is to be "interpreted".
  • gentooflux 1y ago
    The second two lines of your example smell like LoD violations. It's not a formatting problem, it's a structural problem.
    • aleph_minus_one 1y ago
      Sometimes you have to use libraries that are badly designed.
      • gentooflux 1y ago
        When that happens they're usually badly formatted too.
        • aleph_minus_one 1y ago
• gethly 1y ago
  I am quite thankful for Go. It ticks so many boxes. Having native gofmt and simple syntax means I can easily read anyone else's code instantly.
• numtel 1y ago
  With how much LLMs do nowadays, I'm waiting for the time when specifying types is unnecessary. Like, it if can write code, shouldn't we also be able to have an AI type checker?
  • Frieren 1y ago
    Correctness is a key characteristic of a compiler. To have something that sometimes checks the types and some times does is not a feasible solution.
  • IshKebab 1y ago
    Systematic checking like that is pretty much LLM's worst case. They're really bad at it. Definitely better to use them to suggest types.
  • linhns 1y ago
    It writes better when correct type is specified beforehand. So chicken and egg problem you have.
• deleted 1y ago
  [deleted]
• jaimebuelta 1y ago
  I think that formatting code is necessary to maintain a codebase that's used by multiple people and keep some consistency. It's very confusing to have different standards in different parts of the same code. Code should be generally written so it's easy to read.
• pbiggar 1y ago
  This is how darklang works as well.
• rs186 1y ago
  Ah, eslint-config-airbnb. My favorite airbnb config issues: https://github.com/airbnb/javascript/issues/1271 https://github.com/airbnb/javascript/issues/1271 https://github.com/airbnb/javascript/issues/1122 https://github.com/airbnb/javascript/issues/1122 I literally spent over an hour when adapting an existing project to use the airbnb config, when code was perfectly correct, clear and maintainable. I ended up disabling those specific rules locally. I never used it in another project. (Looks like the whole project is no longer maintained. Good riddance.) The airbnb config is, in my view, the perfect example of unnecessarily wasting people's productivity when linting is done badly.
• Perz1val 1y ago
  One thing I absolutely despise is 2 space indentation. Instead of not creating stupid 5+ level deep nesting, people decided to decrease the indentation size. Then everyone uses tab colorizers or those stupid vertical margins in vscode, because you can't read it otherwise. And then those people put it everywhere with some opinionated formatters - looking at you Elixir. I don't even have vision problems and it's already shit to look at.
• Tractor8626 1y ago
  Author advocates for a thing they never used. "It must have been good because Grady Booch says so".
• jillesvangurp 1y ago
  There was a movement towards working with syntax trees directly and treating source code as a generated serialization of those syntax trees about 20-25 years ago. This probably started with refactoring as it was pioneered in the nineties. Things like Visual Age actually stored code in a database instead of on the file system. Later intentional programming (Charles Simonyi was pushing that) tried to also do things with this. And of course model driven development was a thing around the same time. Refactorings (when done right) are syntax tree transformations that preserve things like referential integrity, etc. that ensure code does the same thing before and after applying a refactoring. A rename becomes trivial if you are simply working on the symbol directly. For that to work with file based source trees, you need to parse the whole thing, keep track of where symbols are referred in files, rename the symbol and then update all the places in the source tree. That stuff becomes a lot easier when the code representation isn't a bunch of files but the syntax tree. The symbol just gets a different name. Anything that uses the symbol will still use the same symbol. People like editing files of course and that has resulted in a lot of friction developing richer tools that don't store text but something that preserves more structure. The fact that we're still going on about formatting issues a quarter century later maybe shows that this is something to revisit. For many languages and editors, robust symbol renames are still somewhat science fiction. And that's just the most basic refactoring.
  • zokier 1y ago
    Meh. > That stuff becomes a lot easier when the code representation isn't a bunch of files but the syntax tree You are just mixing abstraction layers here. That syntax tree still needs to be stored in file(s) somehow, and nothing prevents having syntax tree aware (or smarter) tooling operating on human readable files. Basically deserializing AST and parsing source code are the same thing. The storage format really isn't that significant factor here. So what is needed is better tools rather than fiddling with storage format. Microsofts Roslyn is obvious example, but plenty of modern compilers are moving in the direction of exposing APIs to interact with the codebase.
    • jillesvangurp 1y ago
      > That syntax tree still needs to be stored in file(s) somehow Sure, but there are less flaky ways than spreading a syntax tree across files. Visual Age actually used a database for this back in the day. Smalltalk did similar things by storing code in an image file that contained both byte code and method definitions. You could export source code if you wanted. But wouldn't do that while developing typically. That's not an approach that caught on. But it has some advantages. What you are describing is what Eclipse did with Java. Eclipse was the successor to Visual Age. The Eclipse incremental compiler for Java updated an internal data structure for the IDE. It could do neat things as partial compilation to enable running tests even in the presence of some compile errors. It also was really fast. By the time you stopped typing, it would have already compiled your code. Running the tests was similarly fast. The problem of syncing a tree of source files with an AST is just a bit hard. Intellij never came close to this and has always had lots of trouble keeping its internal caches coherent. There's even a top level "invalidate caches" option in the File menu (still there, I checked. Right next to the Repair IDE option). They were off by 2-3 orders of magnitude. Seconds (at best) instead of milliseconds. I still miss Eclipse's speed every day I use Intellij. Some compilers are taking some steps to supporting more advanced IDEs. But there aren't a lot of those beyond what Jetbrains provides. VS Studio Code support varies between different languages. But mostly it's very limited on this front. The Rust compiler is one of those. Though I don't know the current state of that. Mostly it's not well known for its blazing performance (the compiler). I'm not sure if Jetbrains leverages many of those features in its Rust IDE (I'm not a Rust developer).
• fridental 1y ago
  Typing keywords letter by letter is unnecessary too. Think about ZX Spectrum keyboard allowing you to type BASIC keywords with just one key press.
  • cluckindan 1y ago
    Or think about the M (aka MUMPS) language, which allows you to type just the first letter(s) of a keyword and considers it valid syntax. Imagine Java if you could… na com.mycompany.myapp; pu cl MyClass { pro sta i = 42; pri fi ch[] MAGIC = ['a', 'b']; pu sta v main(String[] args) { OtherClass otherClass = n OtherClass(); f (i i = 0; i < MyClass.i; i++) { otherClass.hex(i, this.MAGIC); } } }
  • Cockbrand 1y ago
    Similar, and maybe more related to the article's topic: Commodore BASIC also saved the commands as tokens, so you could enter abbreviated commands like 10 ? "Hello" 20 gO 10 and a LIST command would yield 10 print "Hello" 20 goto 10 So saving commands as tokens in memory and formatting them on output was somewhat common back then. The speccy was more advanced in terms of this (as mentioned in the parent comment), and it had the better BASIC for sure.
  • whartung 1y ago
    This was actually a potential problem, at least on Commodore machines. On those machines you were able to abbreviate keywords. At the same time, they support full screen editing. That meant you could just cursor up over some code, make changes, hit enter, and the changes would take place. However, when using the abbreviations, it was possible to create lines that were too long. I don't recall the specifics, but there was a line limit for BASIC input. Lets say it was 80 chars (for discussion). Using abbreviations (like ? for print) and you could end up with a line that would LIST for more than 80, but if you tried to change it with the screen editor, the lines would be too long, and truncate silently. So you had to be cautious with your use of the abbreviations.
• stared 1y ago
  There are multiple ways to write exactly the same program. Linters are able to reduce this number by moving to some canonical version. With modern tools it it is easy to add formatting on saving or on commit. So I don't understand what's the fuss about. At the same time, for the most important tool in software engineering, Git, it matters which lines are changes. And it is better to only see actual logic changes, not swamped in tabs vs space or other parts that are just formatting. That said, I would love to see more of this splitting between actual internal representation and view. Don't like anything in style guide (or even syntax alike curly brackets vs indentions) - just change view, alike folding.
• ozim 1y ago
  I wouldn’t have an issue if title had „could” instead of should. There are most likely good reasons why Ada and DIANA are not in widespread use.
• jgalt212 1y ago
  line length limits make code harder to grep
• anacrolix 1y ago
  you don't say
• zahlman 1y ago
  > It's 2025, how are we still dealing with this sort of thing? You have to get everyone set up to use it, whereas everyone is already, of necessity, set up to use plain text. And we aren't all using the same programming language and the same hardware setup. Thus, specifically: * everyone has to agree on an IR standard; if it can't accommodate every programming language, then there needs to be coverage for all the programming languages, and a way for software systems to know which one to use * everyone has to have local software that can convert back and forth (they can't just rely on something built in to the "development system", I assume burned into a ROM) * everyone's version control setup has to invoke that software as a commit hook * the IR has to be designed in a way that allows for meaningful diffs, and the version-control software needs to be aware of how to diff and patch (which potentially also means a new standard for diff files)
  • whartung 1y ago
    What "everyone"? They don't have to agree on anything. The poster child for this is Smalltalk. An untraditional environment despite being around 60 years. The source code is stored locally in an internal file tied directly to the runtime image. You can export/import code through "traditional" avenues, but not just anything, it needs to be structured source code. You can't readily move raw text in and out. Despite this impedance mismatch with "the rest of the world", ST folks have been developing code and collaborating for decades. They even manage to get things accomplished. Also, consider many of the modern logging platforms that are logging to databases rather than just raw files. While some grouse about that, others manage to make do. Letting the structured log managers handle the lower level details and provide a better UX. The game is to make sure that your UX for your system is capable of the task, not worrying about interoperating with everyone else.
    • zahlman 1y ago
      > The source code is stored locally in an internal file tied directly to the runtime image. You can export/import code through "traditional" avenues, but not just anything, it needs to be structured source code. You can't readily move raw text in and out. Okay, and what happens when you want to use version control? And what happens when people want to use other text editors? Or are you proposing that each language should have its own complete Smalltalk-style "environment"? > not worrying about interoperating with everyone else. Many programming language ecosystems (notably Python's) would be severely hobbled without all the existing structure built for inter-operation (notably with C, and to a lesser extent Fortran). You can do a lot with pure Python code, but especially for performance reasons Python could never have drawn anywhere near the audience it has without libraries like NumPy.
• paphillips 1y ago
  Ahh yes, nothing brings out the strong opinions like formatting. Let's do SQL next!
• BlueUmarell 1y ago
  Ohhh, a topic about code formatting <picks pop-corns>
• BurningFrog 1y ago
  Code layout is important, even though it - much like naming - doesn't impact functionality. I can write code that (IMHO) is substantially better than any formatter. But I've realized that there is no way to make other people on a team have the same opinions and skill as me, so I accept automatic code formatters.
• oftenwrong 1y ago
  Storing an IR also means we can create languages beyond the limits of syntactical practicality. Imagine, for example, an entire comment/documentation dimension of the code. Instead of commenting on a line near some code, you could attach comments semantically to an expression, or to a variable, or to any unit of code.
  • hliyan 1y ago
    Token, statement and block level annotations would actually be nice. Perhaps even nicer if those annotations could be structured data instead of just text. You could create a truly self-describing code base without having to worry too much about the second hardest problem in programming.
• amdivia 1y ago
  I assume that's something similar to the Unison [1] programming language https://www.unison-lang.org/ https://www.unison-lang.org/
• inetknght 1y ago
  tbqh I would be insanely happy if a formatter would format code the team's way when committing/pushing and my way when I'm viewing locally I've never found a single formatter that formats my way though...
• globular-toast 1y ago
  I feel like squeezing out every possible place for people to be creative and express themselves creates a pretty boring environment. Like, imagine if all buildings were just purely functional. They'd all be the same grey box shaped things. I recently worked on a codebase that was lovingly developed by a single maintainer and had all kinds of weird and wonderful quirks that made me smile every so often. I'm a pretty serious person most of the time but I'm not going to lie it made my day that little bit more interesting.
• giorgioz 1y ago
  In Javascript there is Prettier which auto-formats the code on saving: https://prettier.io/ https://prettier.io/ So essentially you stop caring about adding new lines or tabs, just press save and the code gets indented/formatted correctly.
  • rglynn 1y ago
    I think the point is that: A. not everyone on your team is using prettier B. not everyone is using the same config/agrees on what it should be
    • MaxLeiter 1y ago
      Yeah something I should have covered more is a lot of my frustration comes from the _tooling_ around formatting. Prettier is quite slow, people may not have it setup right, etc.
• stevedekorte 1y ago
  Io (http://iolanguage.org http://iolanguage.org) can work this way, as the message tree (maybe including comments - I don't recall) is what the interpreter used to evaluate the code and is accessible at runtime. However, it didn't store the choice of terminator (newline vs return) or indentation info (though it would be easy to add), so the pretty print of the message tree might look different depending on the source conventions.
• mhh__ 1y ago
  A small point on formatting that I'm getting increasingly firm about as I "age" (still not that old): Formatting is very important, but if you find yourself complaining about what a formatter does to your code, the code be bad (obviously making an exception for a big block of constants or something) e.g. if the formatter is really shifting stuff around, your code might be too nested - if you have a compiler, let it take the strain.
• semiinfinitely 1y ago
  some people do not understand the difference between form and substance
• burnte 1y ago
  Whitespace being important is literally the reason I don't use Python. I'm absolutely TERRIBLE with whitespace in my code, I do not indent like most people, I indent a lot less frequently. I learned coding on TRS80 Model 100 basic, and in DOS with Borland IDEs. Bytes mattered! :D
• grim_io 1y ago
  I came prepared to fight the author, but I left in agreement. Yes, we should expect better from our tools and languages.
• deleted 1y ago
  [deleted]
• GuB-42 1y ago
  And yet, judging by the number of comments, it is definitely not a solved problem :)
• lukaslalinsky 1y ago
  The main selling point for source code in plain text files is compatibility. You can use whatever tool you wish. Yes, it's not ideal, and yes, we are still using non-semantic diffs in these days, even though it should have been a solved problem by now. I'd still argue that even if all the editing/VCS tools start working in a structured way, the storage format should be plain text.
• iLemming 1y ago
  Lua is especially annoying - even after years of using it I just can't really decide how to format it for better readability. lua-fmt sometimes works, often it makes it even worse. I welcomed Fennel in my Lua setups mainly because of this.