3 ms·

> The problem with parsing isn't the difficulty, but rather the potential for endless bikeshedding. You're having to make a ton of opinionated decisions that in

by rewmie 3y ago

> The problem with parsing isn't the difficulty, but rather the potential for endless bikeshedding. You're having to make a ton of opinionated decisions that in turn produce more questions about your syntax. I fail to see your point. OP was commenting on the technical difficulty of actually rolling out a parser, but you're not arguing the technical side. You're arguing the project management sides where "endless bike shedding" results in code churn. That's not the parser's fault, but the person's fault. You're bound to get hung up on details regardless of what part of the project you're working on, because it's not the parser compelling you to get hung up on details.

convolvatron 3y ago
but it is. language syntax design is a total sinkhole. you give me a spec - I'll crap out a parser for you. tell me to design a textual language and chances are pretty good I won't get back to you. and if I do, chances are really high that you're gonna want me to do something different.
- rewmie 3y ago
  > language syntax design is a total sinkhole. Sintax design, not implementing a parser. You're arguing that you might not make up your mind and feel compelled to churn parts of your implementation due to your indecisiveness. That's not the parser's fault, and I fail to see how anyone avoids this indecisiveness by replacing a proper parser with a bunch of ad-hoc hacks. > chances are really high that you're gonna want me to do something different. So what? Just work on it. How many parser generator tools are there? It's as if people have been doing this for decades.
lmm 3y ago
> That's not the parser's fault, but the person's fault. You're bound to get hung up on details regardless of what part of the project you're working on, because it's not the parser compelling you to get hung up on details. Disagree. The fact that you're working on "a parser" creates the bad project structure that leads you to get hung up on details: a parser whose backend doesn't exist yet inherently has unclear requirements and a lot of bikesheddy decisions to make.

by rewmie 3y ago

convolvatron 3y ago

but it is. language syntax design is a total sinkhole. you give me a spec - I'll crap out a parser for you. tell me to design a textual language and chances are pretty good I won't get back to you. and if I do, chances are really high that you're gonna want me to do something different.

rewmie 3y ago
> language syntax design is a total sinkhole. Sintax design, not implementing a parser. You're arguing that you might not make up your mind and feel compelled to churn parts of your implementation due to your indecisiveness. That's not the parser's fault, and I fail to see how anyone avoids this indecisiveness by replacing a proper parser with a bunch of ad-hoc hacks. > chances are really high that you're gonna want me to do something different. So what? Just work on it. How many parser generator tools are there? It's as if people have been doing this for decades.

lmm 3y ago

> That's not the parser's fault, but the person's fault. You're bound to get hung up on details regardless of what part of the project you're working on, because it's not the parser compelling you to get hung up on details. Disagree. The fact that you're working on "a parser" creates the bad project structure that leads you to get hung up on details: a parser whose backend doesn't exist yet inherently has unclear requirements and a lot of bikesheddy decisions to make.