3 ms·

One very simple reason is just a file format. Let's say you want to make a configuration file that's more expressive than JSON or something similar. You reall

One very simple reason is just a file format. Let's say you want to make a configuration file that's more expressive than JSON or something similar. You really don't want to make a Ruby DSL for your configuration file because executing a configuration file is "a really bad idea" (TM) :-) I've made many parsers in my career. I even wrote a SIP parser using antlr which I'm particularly proud of. There are lots of places where you need to parse.

vog 10y ago
Moreover, there are many places where people fiddle with hand-written parser code, nested functions evaluating regexes with many holes and unhandled edge cases - where they should have used a parser generator instead. So my impression is that in general, parser generators are underused, not overused. Anything that encourages people to use parser generators is IMHO a good thing. Ideally, parser generators should become as ubiquitous as template languages, with an similar race between libraries for ease of use, suitability for the most common cases, and lower entry barrier.
- vinceguidry 10y ago
  Templating systems, now that might actually be a use case! But again, there are already lots of templating systems out there. Just pick one and go on with your project. I think I really am just really spoiled by Ruby.
  - vog 10y ago
    > But again, there are already lots of templating systems out there. Just pick one and go on with your project. But that's exactly my point: You can do that for template systems, but not for parser generators. (Well, you can, but your choices aren't nearly as nice.)
    - vinceguidry 10y ago
      Well, sure, but you don't just use parser generators for the hell of it. They have to fit into the broader overall context of a system that drives outcomes. It's easy to see what role a template system can play in such a project, much harder, for me anyway, to see what one would actually use parsing for outside of the rarefied context of building a new general purpose programming language. Anything you'd want to parse, there are already going to be parsers written. Just pick one and go. If you're just screwing around, by all means knock yourself out. But in all the real work serving real humans I've ever done, I have never been able to justify building out a parsing system. I can't even look at a regular expression without wanting to rip it out. I can see if you're maintaining the library that, say, does TOML parsing for Lua. But that's not in the realm of the everyday.
vinceguidry 10y ago
There are lots of configuration formats that already have parsers, why does everyone need their own? TOML, YAML, INI, bash convention, those are just off the top of my head. Whatever you need out of a configuration file format, it's probably already been done, and someone else has already done the hard work of specifying the language and writing a parser for it, all you have to do is hook into it.

vog 10y ago

Moreover, there are many places where people fiddle with hand-written parser code, nested functions evaluating regexes with many holes and unhandled edge cases - where they should have used a parser generator instead. So my impression is that in general, parser generators are underused, not overused. Anything that encourages people to use parser generators is IMHO a good thing. Ideally, parser generators should become as ubiquitous as template languages, with an similar race between libraries for ease of use, suitability for the most common cases, and lower entry barrier.

vinceguidry 10y ago
Templating systems, now that might actually be a use case! But again, there are already lots of templating systems out there. Just pick one and go on with your project. I think I really am just really spoiled by Ruby.
- vog 10y ago
  > But again, there are already lots of templating systems out there. Just pick one and go on with your project. But that's exactly my point: You can do that for template systems, but not for parser generators. (Well, you can, but your choices aren't nearly as nice.)
  - vinceguidry 10y ago
    Well, sure, but you don't just use parser generators for the hell of it. They have to fit into the broader overall context of a system that drives outcomes. It's easy to see what role a template system can play in such a project, much harder, for me anyway, to see what one would actually use parsing for outside of the rarefied context of building a new general purpose programming language. Anything you'd want to parse, there are already going to be parsers written. Just pick one and go. If you're just screwing around, by all means knock yourself out. But in all the real work serving real humans I've ever done, I have never been able to justify building out a parsing system. I can't even look at a regular expression without wanting to rip it out. I can see if you're maintaining the library that, say, does TOML parsing for Lua. But that's not in the realm of the everyday.

vinceguidry 10y ago

There are lots of configuration formats that already have parsers, why does everyone need their own? TOML, YAML, INI, bash convention, those are just off the top of my head. Whatever you need out of a configuration file format, it's probably already been done, and someone else has already done the hard work of specifying the language and writing a parser for it, all you have to do is hook into it.