Detailed writeup of the development of an automatic code formatting tool for the Dart language.
The question of what makes code hard is really interesting.
It seems like what made this particular piece of code was the irregularity of the algorithm, a complex search with irregular exceptions.
You can more easily solve more complex-seeming problems if these can be put into an entirely high level form.
This kind of thing reinforces my prejudice that high level tools, such as functional languages, are not necessarily superior for all purposes.
It also leaves me thinking that the possibilities of even a small length of code are much greater than what one ordinarily creates with standard coding practices and these practices are primarily to make to the code understandable to us.
“Conscious understanding is a thin layer of ice over an ocean of chaos”
A programmer takes some reality, usually abstract and maps it to bits. Just as shining a light on a cup produces a circle from above and a rectangle from the side, we use our mental capacity to project a reality to code.
The challenge of programming is figuring out the appropriate projections for a problem. It is also important to realize that none of our projections are necessarily better universally, but are always colored by goals that are not always rational, like beauty, or morality, or love.
Just as shining a light on a cup produces a circle from above and a rectangle from the side, we use our mental capacity to project a reality to code.
Nice analogy, is it yours?
I’m reminded of the cover to Gödel Escher Bach.
The projection analogy is used throughout math and philosophy, even in religion like Buddhism. I just picked the first object I saw in front of me, which is my coffee cup. :-)
I think that what makes this type of problem “hard to code” is that it is “hard to test”.
If you make a change to this algorithm, you then need to look at the 2M line corpus of dart code, and decide whether the new output is “better” than the old version. And that you didn’t regress anywhere.
Not to be critical, but as a suggestion: I bet you could make the code simpler by aiming to minimize line count instead of aiming to maximize line length.
Once you’ve committed to splitting an expression into multiple lines, you might get better readability by breaking at places that emphasize the structure, versus “these are the three symbols that didn’t fit”. And that would let you use the AST more directly to find split points.