[TUHS] Re: What would early alternatives to C have been?

[Dan Cross <crossd@gmail.com>]

On Mon, Mar 10, 2025 at 11:13 AM Clem Cole <clemc@ccc.com> wrote:
> On Sun, Mar 9, 2025 at 10:03 PM Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
>> Yacc certainly makes it easier to write parsers for big grammars, but it's far from cheating. You need to know a lot more about parsing to use Yacc than you need to roll your own.
>
> I disagree here.  I have wtchged too many young programmers that I realized did not understand what yacc  was doing and came to understanding that never built a simple parse before.

Funny, I agree with both of you, and with Rob. :-)

If I'm not mistaken, I think what Doug was suggesting was that, to
really understand what YACC is _doing_ requires understanding a lot
more about the theory of parsing, grammars, and so on, than one needs
to understand to write a fairly simple RD parser.  RD makes a lot of
sense intuitively, but once you introduce table-driven parsing,
LALR(1), etc, you get into a whole different level of theory and
rigor. Of course, by design the tool abstracts that away from you, so
to just _use_ it you don't necessarily need to understand as much.

>[...]
> The interesting thing is while I tend to use yacc for most parsers, I've found myself building recursive descent parsers in a couple of cases where it seems to make better sense.

Funny, I'm the opposite: I've used YACC for a few parsers, but prefer
to roll my own. I find that I'm either parsing something very simple,
in which case reaching for YACC feels like cutting butter with a
chainsaw, or I need to do something that YACC isn't super great at
(like run in a multithreaded environment). YACC is superb at what it
does, but not something I feel like I need that often.

        - Dan C.