3 ms·

I think Zig is probably just being opinionated there; many of the new languages seem to be overly so. Last I checked, both the Zig and Nim compilers refused (on

by Reelin 7y ago

I think Zig is probably just being opinionated there; many of the new languages seem to be overly so. Last I checked, both the Zig and Nim compilers refused (on principle, not for any technical reason) to compile code containing tabs (among other things). I don't (usually) want my compiler to do linting, and I certainly don't want language authors to dictate my code style from on high.

sullyj3 7y ago
Presumably they're following python's example here.
- Reelin 7y ago
  Python works just fine with tabs, but the language-endorsed style guide (PEP 8) recommends against them. (However, the usual plugin for Vim requires adding "let g:python_recommended_style = 0" to work correctly.)
  - sullyj3 7y ago
    I must've misremembered, possibly what's disallowed is mixing tabs and spaces.
kstenerud 7y ago
Go is also annoying with its anal retentive source rules. I finally got so frustrated that I modified the compiler: https://github.com/kstenerud/go https://github.com/kstenerud/go
- Reelin 7y ago
  It really is a sad state of affairs when disabling the linter requires patching the compiler. I wonder if any of the LLVM-based Go compilers will adopt a saner policy?
- ay 7y ago
  Thank you for this. The passive-aggressive style of erroring on unused variable while staying absolutely silent when I accidentally print the &int variable with %d format, always seemed like an inconsistency to me.
PedroBatista 7y ago
Well, good for them wanting to die on that hill. They will remain dead..
meesles 7y ago
What about Go? It seems like their approach is that if they define the style guide and build it into tooling, your code style (for Go) can only be the 'approved' style. Or, put another way: People only have code styles because languages leave ambiguity. By removing that ambiguity you force your user-base to be consistent therefore increasing communication and productivity. I tend to agree. It really grinds my gears when precious time is wasted on styling issues when there is no technical reason for either side. Granted it can be tough if you use three different languages with three different sets of rules.
- ChrisSD 7y ago
  Rust has grappled with the issue of how far to push styling rules. E.g. from 2016: https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227561639 https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227... I think it's worth reading more of that thread for some pros and cons of being very strict with styling rules. Note that being too strict can lead to code being less readable in specific edge cases. This may or may not be considered a fair trade off.
  - Reelin 7y ago
    To summarize the linked post (which I completely agree with), just provide officially recommended sane defaults and then get out of the user's way. In my view, that's how nearly all software ought to be written.
- Reelin 7y ago
  It's a fundamentally flawed approach in my opinion; viewing the users of a language as a single unified user base is a mistake. Various projects and groups will inevitably have vastly different use cases, and thus needs and considerations. For example, I liberally mix C, C++, D, and occasionally other languages within a single code base on my personal projects. For sanity, I choose to observe my own consistent style across all languages when doing so. This obviously doesn't match common practice for any of the languages in question, but thankfully none of them attempt to impose the opinions of their designers on me. I view languages being concerned with code formatting as a form of scope creep. A language should facilitate good code and communication by thoughtfully designing the syntax and providing useful constructs to the programmer. That's already an incredibly difficult problem - trying to tackle additional interpersonal or organizational issues is far too much, can't possibly accommodate everyone, and is bound to have unexpected negative consequences. Put another way, core infrastructure should nearly always be as unopinionated as possible. Stick to as narrow a design goal as is reasonably possible and execute on it as well as possible. For a language, that means faithfully translating whatever I throw at it into machine code unless there is a legitimate technical barrier in the way of doing so. > It really grinds my gears when precious time is wasted on styling issues when there is no technical reason for either side. If this is happening it's indicative of an organizational or managerial problem. Any given project should have a clearly defined (and consistently enforced) code style, ranging from "use gofmt" to "follow PEP 8" to "adhere to our internal style guide".
naasking 7y ago
> I don't (usually) want my compiler to do linting, and I certainly don't want language authors to dictate my code style from on high. Enforced code style consistency has considerable advantages. "Linting" probably shouldn't be a thing.
- Reelin 7y ago
  Across a specific project, team, or org, sure. That's what style guides, formatters, linters, and pre-commit hooks are for. The core language is the wrong level of abstraction for this stuff.
  - naasking 7y ago
    Yeah, I still disagree. There's considerable value in being sure that you'll see the same code structure everywhere.
BubRoss 7y ago
Making a compiler break with pretty much any file saved from a windows text editor is a very bold opinion, I can't say it would be my choice if I wanted to grow my user base.

by Reelin 7y ago

sullyj3 7y ago

Presumably they're following python's example here.

Reelin 7y ago
Python works just fine with tabs, but the language-endorsed style guide (PEP 8) recommends against them. (However, the usual plugin for Vim requires adding "let g:python_recommended_style = 0" to work correctly.)
- sullyj3 7y ago
  I must've misremembered, possibly what's disallowed is mixing tabs and spaces.

kstenerud 7y ago

Go is also annoying with its anal retentive source rules. I finally got so frustrated that I modified the compiler: https://github.com/kstenerud/go https://github.com/kstenerud/go

Reelin 7y ago
It really is a sad state of affairs when disabling the linter requires patching the compiler. I wonder if any of the LLVM-based Go compilers will adopt a saner policy?
ay 7y ago
Thank you for this. The passive-aggressive style of erroring on unused variable while staying absolutely silent when I accidentally print the &int variable with %d format, always seemed like an inconsistency to me.

PedroBatista 7y ago

Well, good for them wanting to die on that hill. They will remain dead..

meesles 7y ago

What about Go? It seems like their approach is that if they define the style guide and build it into tooling, your code style (for Go) can only be the 'approved' style. Or, put another way: People only have code styles because languages leave ambiguity. By removing that ambiguity you force your user-base to be consistent therefore increasing communication and productivity. I tend to agree. It really grinds my gears when precious time is wasted on styling issues when there is no technical reason for either side. Granted it can be tough if you use three different languages with three different sets of rules.

ChrisSD 7y ago
Rust has grappled with the issue of how far to push styling rules. E.g. from 2016: https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227561639 https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227... I think it's worth reading more of that thread for some pros and cons of being very strict with styling rules. Note that being too strict can lead to code being less readable in specific edge cases. This may or may not be considered a fair trade off.
- Reelin 7y ago
  To summarize the linked post (which I completely agree with), just provide officially recommended sane defaults and then get out of the user's way. In my view, that's how nearly all software ought to be written.
Reelin 7y ago
It's a fundamentally flawed approach in my opinion; viewing the users of a language as a single unified user base is a mistake. Various projects and groups will inevitably have vastly different use cases, and thus needs and considerations. For example, I liberally mix C, C++, D, and occasionally other languages within a single code base on my personal projects. For sanity, I choose to observe my own consistent style across all languages when doing so. This obviously doesn't match common practice for any of the languages in question, but thankfully none of them attempt to impose the opinions of their designers on me. I view languages being concerned with code formatting as a form of scope creep. A language should facilitate good code and communication by thoughtfully designing the syntax and providing useful constructs to the programmer. That's already an incredibly difficult problem - trying to tackle additional interpersonal or organizational issues is far too much, can't possibly accommodate everyone, and is bound to have unexpected negative consequences. Put another way, core infrastructure should nearly always be as unopinionated as possible. Stick to as narrow a design goal as is reasonably possible and execute on it as well as possible. For a language, that means faithfully translating whatever I throw at it into machine code unless there is a legitimate technical barrier in the way of doing so. > It really grinds my gears when precious time is wasted on styling issues when there is no technical reason for either side. If this is happening it's indicative of an organizational or managerial problem. Any given project should have a clearly defined (and consistently enforced) code style, ranging from "use gofmt" to "follow PEP 8" to "adhere to our internal style guide".

naasking 7y ago

> I don't (usually) want my compiler to do linting, and I certainly don't want language authors to dictate my code style from on high. Enforced code style consistency has considerable advantages. "Linting" probably shouldn't be a thing.

Reelin 7y ago
Across a specific project, team, or org, sure. That's what style guides, formatters, linters, and pre-commit hooks are for. The core language is the wrong level of abstraction for this stuff.
- naasking 7y ago
  Yeah, I still disagree. There's considerable value in being sure that you'll see the same code structure everywhere.

BubRoss 7y ago

Making a compiler break with pretty much any file saved from a windows text editor is a very bold opinion, I can't say it would be my choice if I wanted to grow my user base.