40 ms·

An insufficient auto-formatter is very frustrating ... I think there are very smart older programmers who don't appreciate this fact properly. They sort of ha

An insufficient auto-formatter is very frustrating ... I think there are very smart older programmers who don't appreciate this fact properly. They sort of have a belief that there does not exist a "sufficiently good" good code formatter for all users -- and so therefore code formatter should have tons of configuration options to satisfy a range of style choices. I think that opinion belongs in the past (with the discussion of tabs vs spaces). We have witnessed the existence of sufficiently high quality opinionated code formatters (java, gofmt, prettier, ...) -- and these code formatters without style choices produce a better world. The way to get there is to find and prefer the non controversial formatting choices -- that means style preferences are abstracted away and consensus building grows from examples of code that everyone agrees is wrong and wants to fix. The rust formatting issue he highlights makes me really annoyed -- the format chosen by the auto formatter for that sample code is not the best for that situation -- and I'm pretty sure it would be non-controversial for folks to agree on that ... am i right? I'm doing some swift in xcode after awhile using an ide that lets me have "reformat on save" and the experience of "reformat on save" is good enough that I think it probably should be adopted as a first class goal of language designers -- there should be a language level "reformat on save" story that language designers assume will be used ... Baking in reformat on save as an assumed feature at language design time could allow creation or recovery from "write only" syntaxes -- (nice to write but ambiguous to read) -- either added on purpose or by mistake. Would also allow for really powerful Language evolution cleanup opportunities and the opportunity to introduce semantic changes where old functionality is preserved with complete compatibility until the source file is interactively edited from within an editor (eg the semantic change produces a code diff) ...

da39a3ee 6y ago
Whether reformat is called on save is up to your text editor and has nothing to do with the language.
- breatheoften 6y ago
  Yes but there is no reason a language ecosystem can't assumes that this functionality is present, implemented in canonical form, and that it is a language use error not to enable. If the language designers assume the capability exists and will be used -- they can specifically evolve the language based on this assumption. All thats needed is a super high quality, compiler-provided implementation of the functionality -- and to set the expectation -- "sorry you have to wire this functionality up -- otherwise your code is going to be more likely to break if you edit the source files over time while also upgrading your compiler over time." I'm benoaning the fact that no languages I'm aware of have advertised such a position as part of their evolution plan ...
  - da39a3ee 6y ago
    I think that you should have a second think about whether what you're saying makes sense. To "save" some code means that an application writes it to hard drive. But writing to a hard drive is entirely orthogonal to the operation of a compiler. For example, a compiler should be able to compile code that is never written to hard drive -- exists only in memory. The hard drive is just one possible source of code to be compiled. I do agree with you though that autoformatting code on save is a fantastic experience. It works beautifully with Rust, and so now I do it (less beautifully) with Python/black. I just think that although it's a great developer experience, it's several steps removed from anything that anyone would want tied to the compiler.

da39a3ee 6y ago

Whether reformat is called on save is up to your text editor and has nothing to do with the language.

breatheoften 6y ago
Yes but there is no reason a language ecosystem can't assumes that this functionality is present, implemented in canonical form, and that it is a language use error not to enable. If the language designers assume the capability exists and will be used -- they can specifically evolve the language based on this assumption. All thats needed is a super high quality, compiler-provided implementation of the functionality -- and to set the expectation -- "sorry you have to wire this functionality up -- otherwise your code is going to be more likely to break if you edit the source files over time while also upgrading your compiler over time." I'm benoaning the fact that no languages I'm aware of have advertised such a position as part of their evolution plan ...
- da39a3ee 6y ago
  I think that you should have a second think about whether what you're saying makes sense. To "save" some code means that an application writes it to hard drive. But writing to a hard drive is entirely orthogonal to the operation of a compiler. For example, a compiler should be able to compile code that is never written to hard drive -- exists only in memory. The hard drive is just one possible source of code to be compiled. I do agree with you though that autoformatting code on save is a fantastic experience. It works beautifully with Rust, and so now I do it (less beautifully) with Python/black. I just think that although it's a great developer experience, it's several steps removed from anything that anyone would want tied to the compiler.