6 ms·

I think having a single syntax is the best way. I don't want to have to look at python and have to parse spaces, curly braces, square braces, etc. It all being

I think having a single syntax is the best way. I don't want to have to look at python and have to parse spaces, curly braces, square braces, etc. It all being standard is really helpful. A standard Autoformatter like black or gofmt even though I might might not choose all the options, the uniformity is super valuable.

VirusNewbie 2y ago
> I don't want to have to look at python and have to parse spaces, curly braces, square braces, etc. But if the syntax was separate from the underlying representation, couldn't you just have your editor open it the way you want?
- tkuraku 2y ago
  That is true. That seems like a lot of complexity though.
sverhagen 2y ago
This may be controversial, but I find 2-character indented Javascript, coming from my 4-character indented Java, for the projects I work on, as much of a shock as moving between braces and Python. Particularly if it has been subjected to an opinionated formatter that just doesn't match my personal style. Completely unreadable, I mumble under my breath. And then my eyes adjust to it for a bit, and after an... hour? (maybe) of coding in the (ahum) "hostile" style, it's familiar (again) and we're on our way.
- dotancohen 2y ago
  This is why I prefer tabs for indentation. I get to see 4 spaces, the blue haired frontend kid gets to see 2 spaces, and Linus gets to see 8. Everybody's happy.
  - raffraffraff 2y ago
    8?? His neck must be sore.
  - leni536 2y ago
    Sounds good in theory, but I never saw a project that used tabs and didn't look like a complete mess when viewed with the non-blessed tab width.
    - shakna 2y ago
      Pretty sure the Linux source tree looks fine at a tab width of 2 instead of the blessed 8.
    - ahartmetz 2y ago
      Emacs even "helpfully" auto-converts <tab width> spaces to one tab, no matter where.
    - arp242 2y ago
      It's fine as long as you don't use tabs for visual alignment. Especially C projects tend to do this, and/or have a weird mix of tabs and spaces (e.g. indent by four spaces, but all eight spaces are tabs). That's just silly. But if you just always indent by n tabs, and align with spaces for visual alignment, then it's not a problem. This is what e.g. gofmt does.
  - the_other 2y ago
    If you can also get your colleagues to do things like putting their `&&` style logical operators on new lines, then tabs for indents works really well. (This isn't the best example of what I'm getting at, but it's easy to grasp. A stronger example would be the use of ternary operators with multiple lines of JSX. There are many "micro-syntaxes" or "micro-layouts" that help readability and form common patterns in code bases which don't play well with tabs-for-indents, so when you use tabs, you have to train your team to develop and accept novel versions of these "micro-layouts".)
  - RHSeeger 2y ago
    The problem with tabs is that you can't really do alignment with them, unless you have elastic tabs (which are pretty much nowhere). I love the idea of tabs for indentation and spaces for alignment, but even bringing up the idea of using both gets one branded a heretic, so that's out. Which pretty much leaves only spaces if you want to allow for alignment.
    - segfaltnh 2y ago
      For what it's worth, this is how the built in and mandatory Go formatter works and it's "fine".
    - MrJohz 2y ago
      I'm really sceptical of the idea of mixing two different invisible characters in the same file, which is why the tabs+spaces idea makes me feel slightly icky. But another option is just not using alignment spaces at all - if you want to align two parameters/statements/etc, you always split them onto their own lines and use indents directly instead of alignment. In other words, instead of: def my_func(self, param): You always do something like: def my_func( self, param, ):
      - dTal 2y ago
        I tend to agree that you shouldn't be "aligning" things with spaces anyway. If nothing else, it causes diff pollution when the length of a line changes and you have to add or delete spaces to adjacent lines to keep things even, even though no semantic change to those lines has occurred. However, regarding "mixing two different invisible characters in the same file" - you can, and should, configure your text editor to display tabs in a visually distinct way from spaces. Kate (my favorite) shows them as chevrons. Geany and Notepad++ show them as arrows. Not only does this make it easier to scan vertically along an indentation level, but doing so also makes it glaringly obvious if a pesky space has snuck in, resulting in a jarring misalignment.
        RHSeeger 2y ago
        > If nothing else, it causes diff pollution when the length of a line changes and you have to add or delete spaces to adjacent lines to keep things even, even though no semantic change to those lines has occurred. While I agree with this in general, I find making the code nicer to read to be more important that avoiding diff pollution. Especially when that diff pollution can be avoided with a simple "ignore whitespace" in most cases.
_the_inflator 2y ago
I agree. To me ESlint in the JavaScript domain is an unsung hero. Code is so incredibly hard to mentally grasp and every mental overload should be omitted to reflect on the logic. There is a reason why there is one code basis and this should always be curated by a linter to uniformly enforce a standard. There is still plenty of room for style and code organization. I witnessed first hand many trench wars around seemingly small things like curly brackets in IF statements dealing with the question of one white space or none, because it appealed to personal preferences and before ESlint people would go to great length reformatting hundreds of LoCs just to get their right feeling of code syntax. Weird. And git -diff was massive, as well as the code reviews. (Un)Happy times. :D
- hgomersall 2y ago
  I finding reading other people's rust generally delightful because everyone is the same machine controlled style guide (cargo fmt + clippy). It's definitely reduces the mental burden of reading code.
- MrJohz 2y ago
  I recommend Prettier over ESLint - Prettier tends to produce more consistent results and is a lot faster (because it's doing less work). Moreover, ESLint are deprecating the styling rules at the moment (although they'll be made available in a different package). You can configure ESLint to use prettier, but in my experience it's usually easier to just run ESLint separately to prettier.
thejohnconway 2y ago
The whole point is that you don't have to parse different syntax, because you choose your syntax at the editor level.
dTal 2y ago
Your justification for a single syntax is "I don't want to have to look at python and have to parse spaces, curly braces, square braces, etc." But the comment you just replied to said: >Maybe we'd have editors and viewers where you could configure the syntax however you wanted I took this to mean that, in this fantasy universe, you could make any source file look however you want. Like tabs vs spaces and pure html vs html-with-css, this is about separating meaning from presentation. Is there a good reason to force the same visual representation on everyone?
- jefftk 2y ago
  > Is there a good reason to force the same visual representation on everyone? Leaky abstractions. If there are two different visual representations then sometimes someone using one representation will need to think about the other.
  - Spivak 2y ago
    I think this is the best case against a more abstract notion of source code. I don't think you'll ever achieve the dream of heterogeneous representations on a single team unless you somehow get an autoformatter like black to work with both.
    - quectophoton 2y ago
      There's also questions like: * Would such bytecode/binary be considered "source code"? If no, then bye bye Open Source Definition (OSD). Distributing such thing would not be considered open source. * If it is considered "source code", then is it considered "obfuscated" source code? If yes, then bye bye OSD. Distributing such thing would not be considered open source. * If it is not considered "obfuscated" source code, then what's the difference compared to, say, JVM bytecode? Is it only that an IDE exists that can modify such bytecode in a fancy way? * In that case, if such an IDE is created that modifies JVM bytecode directly, and a program is created using that IDE modifying the JVM bytecode[1] directly, and such "source code" is distributed, the would that bytecode be open source? Since, after all, it's "the preferred form in which a programmer would modify the program" (and therefore not obfuscated). [1]: Or maybe some superset that is mostly JVM bytecode but it has some opcodes for higher level niceties.
ok_computer 2y ago
+1 for ruff for python as a formatter & linter that allows single quotes without shaming you. I’m all for keeping consistent flat utf-8 files. I’d hate for my code ultra simpleminded, possible to pen test with a pen and paper, python and sql code to be wrapped in a god awful xml or json or proprietary db markup and object hierarchical model of what code should look like. Like I imagine trying to check in a jupyter notebook but worse. For instance tabs vs spaces was decided and text editors accommodated this and despite what may be someone’s personal preference a uniform decision was made. Humans can learn. We should use accessible formats and push for standards and keep those readable.

VirusNewbie 2y ago

> I don't want to have to look at python and have to parse spaces, curly braces, square braces, etc. But if the syntax was separate from the underlying representation, couldn't you just have your editor open it the way you want?

tkuraku 2y ago
That is true. That seems like a lot of complexity though.

sverhagen 2y ago

This may be controversial, but I find 2-character indented Javascript, coming from my 4-character indented Java, for the projects I work on, as much of a shock as moving between braces and Python. Particularly if it has been subjected to an opinionated formatter that just doesn't match my personal style. Completely unreadable, I mumble under my breath. And then my eyes adjust to it for a bit, and after an... hour? (maybe) of coding in the (ahum) "hostile" style, it's familiar (again) and we're on our way.

dotancohen 2y ago
This is why I prefer tabs for indentation. I get to see 4 spaces, the blue haired frontend kid gets to see 2 spaces, and Linus gets to see 8. Everybody's happy.
- raffraffraff 2y ago
  8?? His neck must be sore.
- leni536 2y ago
  Sounds good in theory, but I never saw a project that used tabs and didn't look like a complete mess when viewed with the non-blessed tab width.
  - shakna 2y ago
    Pretty sure the Linux source tree looks fine at a tab width of 2 instead of the blessed 8.
  - ahartmetz 2y ago
    Emacs even "helpfully" auto-converts <tab width> spaces to one tab, no matter where.
  - arp242 2y ago
    It's fine as long as you don't use tabs for visual alignment. Especially C projects tend to do this, and/or have a weird mix of tabs and spaces (e.g. indent by four spaces, but all eight spaces are tabs). That's just silly. But if you just always indent by n tabs, and align with spaces for visual alignment, then it's not a problem. This is what e.g. gofmt does.
- the_other 2y ago
  If you can also get your colleagues to do things like putting their `&&` style logical operators on new lines, then tabs for indents works really well. (This isn't the best example of what I'm getting at, but it's easy to grasp. A stronger example would be the use of ternary operators with multiple lines of JSX. There are many "micro-syntaxes" or "micro-layouts" that help readability and form common patterns in code bases which don't play well with tabs-for-indents, so when you use tabs, you have to train your team to develop and accept novel versions of these "micro-layouts".)
- RHSeeger 2y ago
  The problem with tabs is that you can't really do alignment with them, unless you have elastic tabs (which are pretty much nowhere). I love the idea of tabs for indentation and spaces for alignment, but even bringing up the idea of using both gets one branded a heretic, so that's out. Which pretty much leaves only spaces if you want to allow for alignment.
  - segfaltnh 2y ago
    For what it's worth, this is how the built in and mandatory Go formatter works and it's "fine".
  - MrJohz 2y ago
    I'm really sceptical of the idea of mixing two different invisible characters in the same file, which is why the tabs+spaces idea makes me feel slightly icky. But another option is just not using alignment spaces at all - if you want to align two parameters/statements/etc, you always split them onto their own lines and use indents directly instead of alignment. In other words, instead of: def my_func(self, param): You always do something like: def my_func( self, param, ):
    - dTal 2y ago
      I tend to agree that you shouldn't be "aligning" things with spaces anyway. If nothing else, it causes diff pollution when the length of a line changes and you have to add or delete spaces to adjacent lines to keep things even, even though no semantic change to those lines has occurred. However, regarding "mixing two different invisible characters in the same file" - you can, and should, configure your text editor to display tabs in a visually distinct way from spaces. Kate (my favorite) shows them as chevrons. Geany and Notepad++ show them as arrows. Not only does this make it easier to scan vertically along an indentation level, but doing so also makes it glaringly obvious if a pesky space has snuck in, resulting in a jarring misalignment.
      - RHSeeger 2y ago
        > If nothing else, it causes diff pollution when the length of a line changes and you have to add or delete spaces to adjacent lines to keep things even, even though no semantic change to those lines has occurred. While I agree with this in general, I find making the code nicer to read to be more important that avoiding diff pollution. Especially when that diff pollution can be avoided with a simple "ignore whitespace" in most cases.

_the_inflator 2y ago

I agree. To me ESlint in the JavaScript domain is an unsung hero. Code is so incredibly hard to mentally grasp and every mental overload should be omitted to reflect on the logic. There is a reason why there is one code basis and this should always be curated by a linter to uniformly enforce a standard. There is still plenty of room for style and code organization. I witnessed first hand many trench wars around seemingly small things like curly brackets in IF statements dealing with the question of one white space or none, because it appealed to personal preferences and before ESlint people would go to great length reformatting hundreds of LoCs just to get their right feeling of code syntax. Weird. And git -diff was massive, as well as the code reviews. (Un)Happy times. :D

hgomersall 2y ago
I finding reading other people's rust generally delightful because everyone is the same machine controlled style guide (cargo fmt + clippy). It's definitely reduces the mental burden of reading code.
MrJohz 2y ago
I recommend Prettier over ESLint - Prettier tends to produce more consistent results and is a lot faster (because it's doing less work). Moreover, ESLint are deprecating the styling rules at the moment (although they'll be made available in a different package). You can configure ESLint to use prettier, but in my experience it's usually easier to just run ESLint separately to prettier.

thejohnconway 2y ago

The whole point is that you don't have to parse different syntax, because you choose your syntax at the editor level.

dTal 2y ago

Your justification for a single syntax is "I don't want to have to look at python and have to parse spaces, curly braces, square braces, etc." But the comment you just replied to said: >Maybe we'd have editors and viewers where you could configure the syntax however you wanted I took this to mean that, in this fantasy universe, you could make any source file look however you want. Like tabs vs spaces and pure html vs html-with-css, this is about separating meaning from presentation. Is there a good reason to force the same visual representation on everyone?

jefftk 2y ago
> Is there a good reason to force the same visual representation on everyone? Leaky abstractions. If there are two different visual representations then sometimes someone using one representation will need to think about the other.
- Spivak 2y ago
  I think this is the best case against a more abstract notion of source code. I don't think you'll ever achieve the dream of heterogeneous representations on a single team unless you somehow get an autoformatter like black to work with both.
  - quectophoton 2y ago
    There's also questions like: * Would such bytecode/binary be considered "source code"? If no, then bye bye Open Source Definition (OSD). Distributing such thing would not be considered open source. * If it is considered "source code", then is it considered "obfuscated" source code? If yes, then bye bye OSD. Distributing such thing would not be considered open source. * If it is not considered "obfuscated" source code, then what's the difference compared to, say, JVM bytecode? Is it only that an IDE exists that can modify such bytecode in a fancy way? * In that case, if such an IDE is created that modifies JVM bytecode directly, and a program is created using that IDE modifying the JVM bytecode[1] directly, and such "source code" is distributed, the would that bytecode be open source? Since, after all, it's "the preferred form in which a programmer would modify the program" (and therefore not obfuscated). [1]: Or maybe some superset that is mostly JVM bytecode but it has some opcodes for higher level niceties.

ok_computer 2y ago

+1 for ruff for python as a formatter & linter that allows single quotes without shaming you. I’m all for keeping consistent flat utf-8 files. I’d hate for my code ultra simpleminded, possible to pen test with a pen and paper, python and sql code to be wrapped in a god awful xml or json or proprietary db markup and object hierarchical model of what code should look like. Like I imagine trying to check in a jupyter notebook but worse. For instance tabs vs spaces was decided and text editors accommodated this and despite what may be someone’s personal preference a uniform decision was made. Humans can learn. We should use accessible formats and push for standards and keep those readable.