4 ms·
Hum, interesting perspective. I did 95% of a masters in CS before leaving to do a startup and while I can see the value of parser generators, there are a LOT of
by ch4s3 3y ago
Hum, interesting perspective. I did 95% of a masters in CS before leaving to do a startup and while I can see the value of parser generators, there are a LOT of times when it is appropriate, useful, and more performant to write your own simple parser. It's often in my opinion the right thing to to first for simple cases. Clearly you should test it and consider functional requirements, but a stringy protocol with clear delimiters is usually dead simple to parse and depending on your use case you can focus on a subset. If you're writing a language... my advice might be different.
- chiefalchemist 3y agoMy impression is the gist is: When you think like an engineer, your focus is on problem solving, and using the appropriate tool(s) to do that. On the other hand, typical developers instinct is to code, code, code; at least based on my experience.
- ch4s3 3y agoI don’t know if you’re trying to be rude, but this comes across as quite disrespectful. Parser tools are indeed very powerful, but those abstractions carry tradeoffs that any “engineer” will consider.
- chiefalchemist 3y agoI wasn't trying to be rude. Sorry? But I also wasn't focused on parser tools. My observation was more universal. That is, engineers look before they leap. Developers leap first and ask questions later. Engineers are intentional. Developers much less so, and far more reactive.
- john_the_writer 3y agoYeah.. I didn't get rude. Sometimes coders just have the NotBuiltHere attitude. I think it's something you grow out of. We can build something, or pull something off the shelf. If it takes x time to build it, and then x time to debug and test and x^(1/0) to maintain it; far better to just add a gem. Even if it's not the absolute best, at least it's easy to understand and if it becomes a problem fix the edges.
- valenterry 3y agoI've never had it once in my career where using a parser generator wasn't better. Given that it's an in-language parser generator and not some meta-language monstrum like ANTLR. Maybe when writing your own programming language, own complicated data format or low communication protocoll while requiring extreme performance. But that seems to be super rare, at least in my area of profession.
- ch4s3 3y agoI’ve had a very different experience. I can think of three occasions where I was able compare a hand written parser with something built using a parser generator or similar tool. In two of those cases, the hand written code was far easier to read and modify. This kind of code can also be easier to test. Parser generators aren’t a free lunch and they vary considerably in quality.
- valenterry 3y agoMaybe we talk about two different things. I'm talking about libraries that help you write a parser. Those are not tools, there is no extra build-process involved or anything like that.
- t43562 3y agoI've worked with people who thought parsers were straighforward and trying to fix the bugs in their code was fraught with impossibility - there can sometimes be millions of ways for parsers to accept invalid input or not accept valid input. In one case I gave up on fixing the code where every change introduced new possible bugs and used a parser generator. We never had another bug in that part of the code but my wholesale change caused intense friction. I feel that a course in parsers would have helped that person to understand this wasn't an appropriate situation. In fact I think it's a good idea to have BNF "that works" before you hand code anything just to confirm that you understand your own language design.