4 ms·

YAGNI is a good principle here. Whenever I've found myself thinking about reaching for a parser library, I was over-complicating or over-generalizing the proble

by TillE 5y ago

YAGNI is a good principle here. Whenever I've found myself thinking about reaching for a parser library, I was over-complicating or over-generalizing the problem. Write the code you need to solve the problem you actually have.

cmyr 5y ago
I agree completely. Anytime I’m looking at a parser library I just shake my head and close that browser tab. I’m invariably going to want a hand-rolled recursive descent parser two weeks later, so let’s just get on it.
- orthoxerox 5y ago
  So much this. I've used a parser generator successfully exactly once, and even then I simply didn't care about proper error reporting. I wouldn't mind something reusable that generated red-green trees for me a la Roslyn. I can bang out a recursive descent parser in a day, but not one that can be run after every keystroke.
- naasking 5y ago
  There's a middle ground with parser combinators.
quotemstr 5y ago
The article makes a good argument against YAGNI, at least YAGNI applied in its naive form. The point is that if you're going to make an embedded language, just do it the right way from the start instead of trying to cobble it together with YAGNI-inspired half-assed implementations that break in weird cases.
TheCoelacanth 5y ago
YAGNI works well as long as you are willing to re-write your code in the rare cases when you do "need it". It's fine to start without a real parser, and you often will end up not ever needing a real one, but if the complexity of your ad hoc solution starts getting anywhere close to the complexity of a real parser, you are better off re-writing it as a real parser because parsing is an extremely well-studied area of CS while your ad-hoc "not parsing" is not.
mcguire 5y ago
Once upon a time, a project I was working on had a particular sub-problem: we sucked in a data file from an external source that consisted of a collection of records that had to be read, validated, and either diddled around in our DB or, in the case of errors, passed off to a human for pondering. The guy who was originally assigned was quite skilled, but apparently he'd never written an interpreter before. He started with the typical Spring Beans Uber Alles infrastructure and processing for the records, but then somehow managed to get pulled off on some other aspect of the project and this part was passed on to me. After my first look at what he had, I realized that error handling, which ranged from misformatted records to nonsensical values, would be a giant ball of razor wire and lemon juice if I continued with his design. So I tossed out much of his infrastructure---keeping his good-record handling---and wrote a simple recursive descent parser that recorded errors (including their locations in the data file) for human processing. The result was simple, clean (if you've seen an interpreter before), and I haven't heard of any bugs reported in it. Turns out, IDNI.

by TillE 5y ago

cmyr 5y ago

I agree completely. Anytime I’m looking at a parser library I just shake my head and close that browser tab. I’m invariably going to want a hand-rolled recursive descent parser two weeks later, so let’s just get on it.

orthoxerox 5y ago
So much this. I've used a parser generator successfully exactly once, and even then I simply didn't care about proper error reporting. I wouldn't mind something reusable that generated red-green trees for me a la Roslyn. I can bang out a recursive descent parser in a day, but not one that can be run after every keystroke.
naasking 5y ago
There's a middle ground with parser combinators.

quotemstr 5y ago

The article makes a good argument against YAGNI, at least YAGNI applied in its naive form. The point is that if you're going to make an embedded language, just do it the right way from the start instead of trying to cobble it together with YAGNI-inspired half-assed implementations that break in weird cases.

TheCoelacanth 5y ago

YAGNI works well as long as you are willing to re-write your code in the rare cases when you do "need it". It's fine to start without a real parser, and you often will end up not ever needing a real one, but if the complexity of your ad hoc solution starts getting anywhere close to the complexity of a real parser, you are better off re-writing it as a real parser because parsing is an extremely well-studied area of CS while your ad-hoc "not parsing" is not.

mcguire 5y ago

Once upon a time, a project I was working on had a particular sub-problem: we sucked in a data file from an external source that consisted of a collection of records that had to be read, validated, and either diddled around in our DB or, in the case of errors, passed off to a human for pondering. The guy who was originally assigned was quite skilled, but apparently he'd never written an interpreter before. He started with the typical Spring Beans Uber Alles infrastructure and processing for the records, but then somehow managed to get pulled off on some other aspect of the project and this part was passed on to me. After my first look at what he had, I realized that error handling, which ranged from misformatted records to nonsensical values, would be a giant ball of razor wire and lemon juice if I continued with his design. So I tossed out much of his infrastructure---keeping his good-record handling---and wrote a simple recursive descent parser that recorded errors (including their locations in the data file) for human processing. The result was simple, clean (if you've seen an interpreter before), and I haven't heard of any bugs reported in it. Turns out, IDNI.