[Grbl_Esp32 PR#585] Attempted to weed out all trivial defines – not for merge

#1 – ggallant571 于 2020-09-08

As a bystander I can’t help but notice a lot of effort being directed at
issues that are self induced based more on “religious” preference than
practical needs. Perhaps it is time need to rename the project. To me,
“grbl” in the name implies a product/standard that has a reputation for
a solid reliability no nonsense no-frills performance.

#2 – MitchBradley 于 2020-09-08

We are trying very hard to maintain no-questions-asked compatibility with “classic Grbl”, so that existing senders will “Just Work”. The desire to adhere to outdated coding standards is every bit as “religious” as the desire to use more modern ones. We have specific reasons for our changes. For example, the more expressive typing via the use of scoped enumerations and the like permits the compiler to find obscure errors that might otherwise go undetected; it has already found some. It also permits us to add features that were otherwise quite difficult to add in a reliable fashion. The “no frills” nature of GRBL is an artifact of the constrained 8-bit AVR environment in which it was developed. That became a serious limitation long ago; the switch from GRBL 0.9 to 1.1 broke a lot of senders because the protocol had to change as a result of insufficient ROM space. At that point, classic GRBL ran out of room to grow. You can look at that as a virtue or a failing, depending on your point of view. We are interested in making machines that are more powerful and easier to configure than is possible with classic GRBL, while retaining a very high level of compatibility with existing GRBL GCode senders. The switch to modern coding conventions supports that goal.