4 ms·

The key difference you are outlining here is form vs function. The latter example is perfectly reasonable because you are adding actual “content” and restructur

by rusk 3y ago

The key difference you are outlining here is form vs function. The latter example is perfectly reasonable because you are adding actual “content” and restructuring around that. I don’t think any reasonable person could object to that - coding guidelines bedamned. GP’s example is just finicky window dressing based on indulging a personal aesthetic based on what the author things “looks good” on a particular day, with a particular font on a particular screen. What we should be striving for in code style is the lowest common denominator most bare bones strucure that can be read, understood and modified with the most rudimentary of tools. EDIT > What happened to "code is primarily to be read, occasionally to be executed"? Exactly this. Code should be readable for all. It goes through all sorts of other actors and tooling, not just your painstakingly configured IDE. >> What we should be striving for in code style is the lowest common denominator most bare bones strucure that can be read, understood and modified with the most rudimentary of tools. > as if, when designing a building, everyone involved - architects, plumbers, electricians, HVAC engineers … All the above have to abide by building codes, use standardised parts and tools and most have to conform to certified standards which their work is then also validated against. We have many, many coding standards most of which discourage tabs and fancy formatting but developers get special exemption because “ma creativiteh” > plaintext code directly is an idea that needs to die. Yes let’s throw out some things that work perfectly well to accommodate a few malcontent crybabies. At the end of the day our laws and most of our written communication depends heavily on plaintext and that’s not gona change any time soon just because a few people don’t want to learn how to use it properly.

TeMPOraL 3y ago
> What we should be striving for in code style is the lowest common denominator most bare bones structure that can be read, understood and modified with the most rudimentary of tools. What happened to "code is primarily to be read, occasionally to be executed"? You're suggesting we should be optimizing for the wrong thing. To be honest, this is just another unsolvable issue that's a direct result of us insisting on keeping the code as plaintext and insisting we work directly on it and only it, the single source of truth, using bare-bones tools. It's really as dumb as if, when designing a building, everyone involved - architects, plumbers, electricians, HVAC engineers, decorators, landscapers and others - were forced to use the same, single, canonical, flat technical drawing. You can imagine they'd be wasting much time on endless holy wars on the right drawing scale, right colors, line thickness, where to put the legend, how to make annotations, etc. - where the real problem is that a single flat piece of paper (or digital equivalent) can't possibly accommodate all their needs at the same time. We're like that, and here we're discussing whether to align labels on the drawing to the left or to the right, in hopes it'll somehow make an impenetrably dense drawing an iota more readable. We're going as far as to play with dark monadic magick, inventing convoluted drawing techniques in order to somehow squeeze layout of cables, water pipes and air vents in a way that makes decorators shut up about not being able to visualize the building in their heads, because the plan is too dense or too non-local or whatnot. And we're so proud that we automated the ability to xerox the plan for different teams to add more squiggles independently, and then merge them into a new unified plan the next day, and even have an audit trail by putting SHAs on everything. Seriously, our whole approach and tooling ecosystem is tripling down on idiocy. Editing the same, single source of truth, plaintext code directly is an idea that needs to die.
- Etherlord87 3y ago
  > Seriously, our whole approach and tooling ecosystem is tripling down on idiocy. Editing the same, single source of truth, plaintext code directly is an idea that needs to die. I use Obsidian, because it's a cool notepad software that stores everything as plain text. This means at any point in time, if Obsidian stops being developed (and supported by up-to-date OSes), or there's a new better software, or stops being free to use - I can just stop using it, and I still have my notes. This is just one of many strengths of the plain text. Compatibility is another. I know, I'm not actually editing those plain text files directly. I can, however.
  - TeMPOraL 3y ago
    Plain text as a storage format is fine; it's inefficient, but has longevity benefits you mention. Plain text as representation to read, write and edit is also fine - many things are best expressed this way, and text lends itself to be edited efficiently by advanced tools (e.g. vim, Emacs, or sed, awk, etc.) The issue is not with either of them alone. The problem seems from using the same plaintext documents for both storage and representation simultaneously. The solution is to have a storage format optimized for storage - which could just as well stay plaintext - but all reading, writing and editing to be done through tools that render you a representation best suited for what you need at the moment. This could be plaintext prose now, plaintext code an hour from now, and a pile of editable, graphical state machine diagrams tomorrow.
    - rusk 3y ago
      > The solution is to have a storage format optimized for storage Plaintext is for interchange not storage. You can optimise for storage by putting .gz on the end of it. > writing and editing to be done through tools that render you a representation best suited for what you need at the moment. XML? XSLT? This has been tried and it’s easily done if you want nobody to like you. The crux of the issue is interchange. Neither of the things you have so vociferously decried. As usual, somewhere in the middle. The lowest common denominator is plain text and that’s what works best en masse for all the participants and tooling.
Etherlord87 3y ago
> All the above have to abide by building codes, use standardised parts and tools and most have to conform to certified standards which their work is then also validated against. This is a huge logical error. You just proposed to use the lowest common denominator, but then your response to the analogy is that other people are constrained by rules. Yes, they are constrained by rules, that are very complex, and even then, the constraint ensures a minimal standard, it doesn't block you from creativity. Fire prevention rules will define how wide a corridor has to be, but it won't forbid you to build a wider corridor or to paint its walls. BTW editing your post to answer a post below you wasn't the smartest thing to do…
- rusk 3y ago
  No I meant the standardised approach is the lowest common denominator. It’s the least common unit that has been agreed upon. Category Error at worst, but well within colloquial bounds.

by rusk 3y ago

TeMPOraL 3y ago

> What we should be striving for in code style is the lowest common denominator most bare bones structure that can be read, understood and modified with the most rudimentary of tools. What happened to "code is primarily to be read, occasionally to be executed"? You're suggesting we should be optimizing for the wrong thing. To be honest, this is just another unsolvable issue that's a direct result of us insisting on keeping the code as plaintext and insisting we work directly on it and only it, the single source of truth, using bare-bones tools. It's really as dumb as if, when designing a building, everyone involved - architects, plumbers, electricians, HVAC engineers, decorators, landscapers and others - were forced to use the same, single, canonical, flat technical drawing. You can imagine they'd be wasting much time on endless holy wars on the right drawing scale, right colors, line thickness, where to put the legend, how to make annotations, etc. - where the real problem is that a single flat piece of paper (or digital equivalent) can't possibly accommodate all their needs at the same time. We're like that, and here we're discussing whether to align labels on the drawing to the left or to the right, in hopes it'll somehow make an impenetrably dense drawing an iota more readable. We're going as far as to play with dark monadic magick, inventing convoluted drawing techniques in order to somehow squeeze layout of cables, water pipes and air vents in a way that makes decorators shut up about not being able to visualize the building in their heads, because the plan is too dense or too non-local or whatnot. And we're so proud that we automated the ability to xerox the plan for different teams to add more squiggles independently, and then merge them into a new unified plan the next day, and even have an audit trail by putting SHAs on everything. Seriously, our whole approach and tooling ecosystem is tripling down on idiocy. Editing the same, single source of truth, plaintext code directly is an idea that needs to die.

Etherlord87 3y ago
> Seriously, our whole approach and tooling ecosystem is tripling down on idiocy. Editing the same, single source of truth, plaintext code directly is an idea that needs to die. I use Obsidian, because it's a cool notepad software that stores everything as plain text. This means at any point in time, if Obsidian stops being developed (and supported by up-to-date OSes), or there's a new better software, or stops being free to use - I can just stop using it, and I still have my notes. This is just one of many strengths of the plain text. Compatibility is another. I know, I'm not actually editing those plain text files directly. I can, however.
- TeMPOraL 3y ago
  Plain text as a storage format is fine; it's inefficient, but has longevity benefits you mention. Plain text as representation to read, write and edit is also fine - many things are best expressed this way, and text lends itself to be edited efficiently by advanced tools (e.g. vim, Emacs, or sed, awk, etc.) The issue is not with either of them alone. The problem seems from using the same plaintext documents for both storage and representation simultaneously. The solution is to have a storage format optimized for storage - which could just as well stay plaintext - but all reading, writing and editing to be done through tools that render you a representation best suited for what you need at the moment. This could be plaintext prose now, plaintext code an hour from now, and a pile of editable, graphical state machine diagrams tomorrow.
  - rusk 3y ago
    > The solution is to have a storage format optimized for storage Plaintext is for interchange not storage. You can optimise for storage by putting .gz on the end of it. > writing and editing to be done through tools that render you a representation best suited for what you need at the moment. XML? XSLT? This has been tried and it’s easily done if you want nobody to like you. The crux of the issue is interchange. Neither of the things you have so vociferously decried. As usual, somewhere in the middle. The lowest common denominator is plain text and that’s what works best en masse for all the participants and tooling.

Etherlord87 3y ago

> All the above have to abide by building codes, use standardised parts and tools and most have to conform to certified standards which their work is then also validated against. This is a huge logical error. You just proposed to use the lowest common denominator, but then your response to the analogy is that other people are constrained by rules. Yes, they are constrained by rules, that are very complex, and even then, the constraint ensures a minimal standard, it doesn't block you from creativity. Fire prevention rules will define how wide a corridor has to be, but it won't forbid you to build a wider corridor or to paint its walls. BTW editing your post to answer a post below you wasn't the smartest thing to do…

rusk 3y ago
No I meant the standardised approach is the lowest common denominator. It’s the least common unit that has been agreed upon. Category Error at worst, but well within colloquial bounds.