4 ms·
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 e
by 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 agoI 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.