4 ms·

I hold the opinion that formatting should not be a part of source code, I should rather be held in a separate style sheet. Source code should then contain only

I hold the opinion that formatting should not be a part of source code, I should rather be held in a separate style sheet. Source code should then contain only logic. Tha way I can set my editor to tabs, my coworker can set it to spaces and none of that ends up in the source code - the source just says that there's a block of blank space and the Style sheet tells the editor/IDE how to present it. In a similar way, things like braces placement (or no braces like in Python) or capitalisation can be kept out of source code and in a style sheet. (That way, I'll never have to dig through white space and formatting changes in git logs any more to find actual changes to the code.)

enriquto 9y ago
For some reason, I find this idea extremely disturbing; almost dystopian. To me, the sentence "a program is a text file" is one of the first axioms of computer technology.
- throwaway91111 9y ago
  But—only in very metaphorical ways is a program a text file.
  - enriquto 9y ago
    How is that metaphorical at all? In all current languages, you write programs precisely by writing text files.
    - coldtea 9y ago
      For one, in that a running program is not a text file -- it has been parsed into an AST, processed in various pipelines, and converted into several forms before it even hits a register...
      - enriquto 9y ago
        On the other hand, you can compile the same program with different optimization options, and even on different architectures, and we say that it is always the same program, but the binary objects may be wildly different. Thus, the program is the text file, not the binary object.
        MereInterest 9y ago
        I can add blank lines, change variable names, add comments, and yet through all these changes, it is the same program. By your logic, then, none of them can be the "real" program, just as none of the different binaries could be the "real" program. I think that it is better to think of all of these as representations of the same abstract program. The Sieve of Eratosthenes can be implemented in different languages, binary or assembler, high-level or low-level, English or code, but they are all representations of the same abstract program.
    - fasquoika 9y ago
      Strictly speaking though, the text itself isn't a program, it's the input to a program (a compiler) that produces an actual program. On the other hand, this definition seems a little pedantic and you could even argue that the binary produced by the compiler isn't a program either, that a program consists entirely of its behavior.
      - Koshkin 9y ago
        Generally, this is not correct - compiling is not the only way to "translate" a program into an executable form: there are direct interpreters for many programming languages.
        fasquoika 9y ago
        I never said compiling was the only way, just that "translation" (as you put it) is in fact necessary.
    - geoffpado 9y ago
      In all current _serious_ languages, maybe, but also Piet exists: http://www.dangermouse.net/esoteric/piet.html http://www.dangermouse.net/esoteric/piet.html
- Terr_ 9y ago
  I think it's fair to say that all programs are written artifacts as opposed to visual ones. The few visually oriented programming languages haven't really taken off. However, it doesn't necessarily have to be the plainest of plain text. Even today, it is ridiculously popular for people to use syntax-highlighting, which adds color to everything they do. It might not get stored to the disk, but it shows that the experience of writing/reading code goes far beyond the purely textual. Other things to consider: Code-block folding; call-graph and type-hierarchy visualizations; GUI tools for files that are half-generated and half-written; the way that diff tools turn text differences into a visual experience... In other words, while storing your creative output in a simple and consistent way is good, the craft of programming has organically added many visual interactions to match the strengths and weaknesses of our human brains. It's not unreasonable to expect more of that, even if the core remains a written conversation with an idiot savant computer.
pshc 9y ago
Agreed. Source code being "denormalized" as plaintext brings practicality, yet also problems like structure-indentation mismatch, or having merge conflicts over a trivial rename. Writing a non-plaintext editor is a huge UI/UX problem, however...
- coldtea 9y ago
  Huh? On the contrary, it's very easy. Smalltalk environments used to it, Lisp machines could do it, etc. Even the combination (programmer edits code as text, but in fact just manipulates a structure, which on the programming environment has all the cool properties of live code --knowledge of structure, easy refactoring, etc-- but at the end is again saved as text and works with all tools like Git etc) is trivial to make.
  - pshc 9y ago
    Okay, allow me to clarify. A structure editor that has an all-around experience superior to plaintext editing, to the extent that such an editor can gain critical mass/mainstream adoption, remains an unsolved problem.
ue_ 9y ago
I can't really see a reason why source files should only be logic. For a long time we've operated on the principle that they ought to be readable too, because humans write them. So there are comments, formatting, and styles of programming to make what you're doing readable to others, like choice of variable names. Decide on a "stylesheet" to use with the people with whom you're working with, and try to stick to it. In a way tabs are an invitation to style them how you want.
Ace17 9y ago
Code formatting mostly is a solved issue. Configure a tool like clang-format/uncrustify, and make it run automatically by your test scripts. We've been doing this at work for years, and I'm still amazed at the results: nobody cares about the coding style anymore, and the code is perfectly homogenous (and the logs/diffs are 99% clean from formatting concerns).

enriquto 9y ago

For some reason, I find this idea extremely disturbing; almost dystopian. To me, the sentence "a program is a text file" is one of the first axioms of computer technology.

throwaway91111 9y ago
But—only in very metaphorical ways is a program a text file.
- enriquto 9y ago
  How is that metaphorical at all? In all current languages, you write programs precisely by writing text files.
  - coldtea 9y ago
    For one, in that a running program is not a text file -- it has been parsed into an AST, processed in various pipelines, and converted into several forms before it even hits a register...
    - enriquto 9y ago
      On the other hand, you can compile the same program with different optimization options, and even on different architectures, and we say that it is always the same program, but the binary objects may be wildly different. Thus, the program is the text file, not the binary object.
      - MereInterest 9y ago
        I can add blank lines, change variable names, add comments, and yet through all these changes, it is the same program. By your logic, then, none of them can be the "real" program, just as none of the different binaries could be the "real" program. I think that it is better to think of all of these as representations of the same abstract program. The Sieve of Eratosthenes can be implemented in different languages, binary or assembler, high-level or low-level, English or code, but they are all representations of the same abstract program.
  - fasquoika 9y ago
    Strictly speaking though, the text itself isn't a program, it's the input to a program (a compiler) that produces an actual program. On the other hand, this definition seems a little pedantic and you could even argue that the binary produced by the compiler isn't a program either, that a program consists entirely of its behavior.
    - Koshkin 9y ago
      Generally, this is not correct - compiling is not the only way to "translate" a program into an executable form: there are direct interpreters for many programming languages.
      - fasquoika 9y ago
        I never said compiling was the only way, just that "translation" (as you put it) is in fact necessary.
  - geoffpado 9y ago
    In all current _serious_ languages, maybe, but also Piet exists: http://www.dangermouse.net/esoteric/piet.html http://www.dangermouse.net/esoteric/piet.html
Terr_ 9y ago
I think it's fair to say that all programs are written artifacts as opposed to visual ones. The few visually oriented programming languages haven't really taken off. However, it doesn't necessarily have to be the plainest of plain text. Even today, it is ridiculously popular for people to use syntax-highlighting, which adds color to everything they do. It might not get stored to the disk, but it shows that the experience of writing/reading code goes far beyond the purely textual. Other things to consider: Code-block folding; call-graph and type-hierarchy visualizations; GUI tools for files that are half-generated and half-written; the way that diff tools turn text differences into a visual experience... In other words, while storing your creative output in a simple and consistent way is good, the craft of programming has organically added many visual interactions to match the strengths and weaknesses of our human brains. It's not unreasonable to expect more of that, even if the core remains a written conversation with an idiot savant computer.

pshc 9y ago

Agreed. Source code being "denormalized" as plaintext brings practicality, yet also problems like structure-indentation mismatch, or having merge conflicts over a trivial rename. Writing a non-plaintext editor is a huge UI/UX problem, however...

coldtea 9y ago
Huh? On the contrary, it's very easy. Smalltalk environments used to it, Lisp machines could do it, etc. Even the combination (programmer edits code as text, but in fact just manipulates a structure, which on the programming environment has all the cool properties of live code --knowledge of structure, easy refactoring, etc-- but at the end is again saved as text and works with all tools like Git etc) is trivial to make.
- pshc 9y ago
  Okay, allow me to clarify. A structure editor that has an all-around experience superior to plaintext editing, to the extent that such an editor can gain critical mass/mainstream adoption, remains an unsolved problem.

ue_ 9y ago

I can't really see a reason why source files should only be logic. For a long time we've operated on the principle that they ought to be readable too, because humans write them. So there are comments, formatting, and styles of programming to make what you're doing readable to others, like choice of variable names. Decide on a "stylesheet" to use with the people with whom you're working with, and try to stick to it. In a way tabs are an invitation to style them how you want.

Ace17 9y ago

Code formatting mostly is a solved issue. Configure a tool like clang-format/uncrustify, and make it run automatically by your test scripts. We've been doing this at work for years, and I'm still amazed at the results: nobody cares about the coding style anymore, and the code is perfectly homogenous (and the logs/diffs are 99% clean from formatting concerns).