3 ms·

Linters typically operate on the AST for your code, though, and differences between your linter's grammar and the real grammar can cause headaches. More ambiti

Linters typically operate on the AST for your code, though, and differences between your linter's grammar and the real grammar can cause headaches. More ambitiously, I think there's a huge amount we could be doing with ASTs, where right now we're mostly kludging along with line-based tools. Merging/diffing is one example. I've run up against some truly gnarly merge situations, in particular with indentation based languages, where automatic merging did what could best be described as "stirring" the code, and manual merging was like pulling teeth. It's bizarre to me that in 2017, we're still using tools that act like our source code files are made of unstructured lines of text, instead of exploiting the precise structure that the language imposes. I don't know of any remotely mature tools that try to solve this problem, although I've seen some more research-like projects. The potential gains seem huge. For example, imagine renaming a method throughout your project, and having no merge conflicts with your teammates, even when they change the same lines where that method is called. (Or at least, imagine having a merge tool that proposes the correct merge for your approval.) But if we're going to move toward tools like that, languages without formal specifications are an obstacle.

delhanty 9y ago
>... there's a huge amount we could be doing with ASTs, where right now we're mostly kludging along with line-based tools. Merging/diffing is one example. ... Strongly agree - seems a strange situation to me. The line-based thinking that still dominates the majority *nix has some advantages but also does seem to impede progress. It reminds me that I meant to read Rob Pikes "Structural Regular Expressions" [0]. (ht #pmoriarty - from HN mid-November [1]) Furthermore, even if there is well-defined AST available, it doesn't mean it will be used. XML based formats for example - e.g. see here: [2] If we could even semi-automatically merge Microsoft's Office Open XML formats [3] anywhere using the associated AST that would surely create huge value for lots of businesses. [0] http://doc.cat-v.org/bell_labs/structural_regexps/se.pdf http://doc.cat-v.org/bell_labs/structural_regexps/se.pdf [1] https://news.ycombinator.com/item?id=15714169 https://news.ycombinator.com/item?id=15714169 [2] https://joepairman.com/posts/xml-in-git-mercurial-watch-out-for-merges https://joepairman.com/posts/xml-in-git-mercurial-watch-out-... [3] https://en.wikipedia.org/wiki/Office_Open_XML https://en.wikipedia.org/wiki/Office_Open_XML

delhanty 9y ago

>... there's a huge amount we could be doing with ASTs, where right now we're mostly kludging along with line-based tools. Merging/diffing is one example. ... Strongly agree - seems a strange situation to me. The line-based thinking that still dominates the majority *nix has some advantages but also does seem to impede progress. It reminds me that I meant to read Rob Pikes "Structural Regular Expressions" [0]. (ht #pmoriarty - from HN mid-November [1]) Furthermore, even if there is well-defined AST available, it doesn't mean it will be used. XML based formats for example - e.g. see here: [2] If we could even semi-automatically merge Microsoft's Office Open XML formats [3] anywhere using the associated AST that would surely create huge value for lots of businesses. [0] http://doc.cat-v.org/bell_labs/structural_regexps/se.pdf http://doc.cat-v.org/bell_labs/structural_regexps/se.pdf [1] https://news.ycombinator.com/item?id=15714169 https://news.ycombinator.com/item?id=15714169 [2] https://joepairman.com/posts/xml-in-git-mercurial-watch-out-for-merges https://joepairman.com/posts/xml-in-git-mercurial-watch-out-... [3] https://en.wikipedia.org/wiki/Office_Open_XML https://en.wikipedia.org/wiki/Office_Open_XML