4 ms·

I think the second-hardest thing is to accept that CS spent decades optimizing parsing algorithms and grammars, and this is still a significant part of CS curri

I think the second-hardest thing is to accept that CS spent decades optimizing parsing algorithms and grammars, and this is still a significant part of CS curricula in many places. But the practical reality is that parsing is almost never a bottleneck. If what you're parsing is within the capacity of humans to interact with (so in the range of tens of kilobytes), a grammar that requires an O(N^2) parser is totally fine.

haileys 2mo ago
An O(n^2) parser is not fine for the mere reason that I don't know how one would make such a mess of the job in the first place. A simple recursive-descent parser is easy to write by hand and runs in linear time.
- mhast 2mo ago
  I think the point was that even if you managed to make a O(n*2) parser it will ve fast enough for human entered problems.
  - srean 2mo ago
    Not for C++ code generated by whole program optimizing compilers. Your "human entered" is doing the heavy lifting. Now that AI is writing code your assertion might be on shaky ground.
    - simonask 2mo ago
      C++ can be slow to compile, but as I said, parsing is not the bottleneck. Even for really huge automatically generated C++ files, or old-school concatenated "unity builds", the parsing step is generally tiny compared to everything else.
    - aw1621107 2mo ago
      > Not for C++ code generated by whole program optimizing compilers. I'd be quite surprised if an optimizing compiler generated C++ code somewhere in its pipeline!
      - pjmlp 2mo ago
        C++26 reflection?
        aw1621107 2mo ago
        Oh, true! That's on me for not being specific enough. I was thinking about the optimization pipeline.
      - srean 2mo ago
        Take a look at Felix. https://felix-lang.github.io/felix/ https://felix-lang.github.io/felix/ Ignore the 'scripting' language claim.
        aw1621107 2mo ago
        Oh, that is certainly not what I was expecting at all. I stand corrected! I do have to wonder though - do you know what proportion of the C++ compiler time is spent parsing your generated C++ code vs. optimizing it?
        srean 2mo ago
        Unfortunately no. Felix is quite old at this point. It's a very interesting language, with many interesting ideas. It did not quite take off though.
        aw1621107 2mo ago
        What favorite feature(s) do you miss when working in other languages?
        srean 2mo ago
        Coroutines, cooperative threading using fibres, type classes, generics, type deduction, easy interface with C++. The functional style, pattern matching. Flow based programming using 'chips and wires' abstraction. It has many other interesting capabilities, for example, the ability to change its own grammar, that is rather too much, not for a pleb like me. It has unique (linear and affine) types too. It is really quite a handful. Go did bring coroutines back into limelight but Felix predates Go by a margin. Skaller, Felix's author, used Felix as a playground for novel language design ideas, so it was always in a state of flux.
- nly 2mo ago
  Recursive descent isnt guaranteed linear time In the face of backtracking the time depends on the complexity of the grammar, since it's basically a brute force search through all the rules.
- adev_ 2mo ago
  > A simple recursive-descent parser is easy to write by hand and runs in linear time. Recursive descenrs parsers are not linear. They are generally O(n^2) and can even can go exponential with some grammars if written naively. It can be pretty easy to do adverserival attacks on most naive descent parser and bring it to its knees. Packrat parser [^1] are linear, but they are by no means "trivial 200 lines" type of parsers. [^1]: https://arxiv.org/abs/cs/0603077 https://arxiv.org/abs/cs/0603077
bregma 2mo ago
I don't think it is difficult to accept that fundamentals should be taught. We spend years learning basic arithmetic like the addition of integers. You could very well argue that there is no need for that either because everyone has a calculator app on their phone. This is how dark ages begin.
- sacado2 2mo ago
  It drives me crazy how so many people (of all ages) can't do basic math in their head, at least approximately. You need it constantly and it's so much faster than picking up your phone, starting the app, and typing in the operation. I'm so glad my teachers back in the 80s and 90s told me "you won't always have a calculator in your pocket". They were wrong (I do have one) but they were right (it's not always convenient to rely on a calculator).
nly 2mo ago
It's "fine" is you ignore adversarial situations. If someone is taking malicious stabs at your API then you have a problem
- simonask 2mo ago
  Yeah, absolutely. I would be worried about a JSON parser facing the internet that had these kinds of problems, for example. But it's only the very first in a long line of potential vulnerabilities such a system has to consider. What good is a perfect linear-time constant-space parser if the next thing the system does is to allocate hundreds of megabytes of objects representing some deserialized data structure? The parser is usually the least interesting part.

haileys 2mo ago

An O(n^2) parser is not fine for the mere reason that I don't know how one would make such a mess of the job in the first place. A simple recursive-descent parser is easy to write by hand and runs in linear time.

mhast 2mo ago
I think the point was that even if you managed to make a O(n*2) parser it will ve fast enough for human entered problems.
- srean 2mo ago
  Not for C++ code generated by whole program optimizing compilers. Your "human entered" is doing the heavy lifting. Now that AI is writing code your assertion might be on shaky ground.
  - simonask 2mo ago
    C++ can be slow to compile, but as I said, parsing is not the bottleneck. Even for really huge automatically generated C++ files, or old-school concatenated "unity builds", the parsing step is generally tiny compared to everything else.
  - aw1621107 2mo ago
    > Not for C++ code generated by whole program optimizing compilers. I'd be quite surprised if an optimizing compiler generated C++ code somewhere in its pipeline!
    - pjmlp 2mo ago
      C++26 reflection?
      - aw1621107 2mo ago
        Oh, true! That's on me for not being specific enough. I was thinking about the optimization pipeline.
    - srean 2mo ago
      Take a look at Felix. https://felix-lang.github.io/felix/ https://felix-lang.github.io/felix/ Ignore the 'scripting' language claim.
      - aw1621107 2mo ago
        Oh, that is certainly not what I was expecting at all. I stand corrected! I do have to wonder though - do you know what proportion of the C++ compiler time is spent parsing your generated C++ code vs. optimizing it?
        srean 2mo ago
        Unfortunately no. Felix is quite old at this point. It's a very interesting language, with many interesting ideas. It did not quite take off though.
        aw1621107 2mo ago
        What favorite feature(s) do you miss when working in other languages?
        srean 2mo ago
        Coroutines, cooperative threading using fibres, type classes, generics, type deduction, easy interface with C++. The functional style, pattern matching. Flow based programming using 'chips and wires' abstraction. It has many other interesting capabilities, for example, the ability to change its own grammar, that is rather too much, not for a pleb like me. It has unique (linear and affine) types too. It is really quite a handful. Go did bring coroutines back into limelight but Felix predates Go by a margin. Skaller, Felix's author, used Felix as a playground for novel language design ideas, so it was always in a state of flux.
nly 2mo ago
Recursive descent isnt guaranteed linear time In the face of backtracking the time depends on the complexity of the grammar, since it's basically a brute force search through all the rules.
adev_ 2mo ago
> A simple recursive-descent parser is easy to write by hand and runs in linear time. Recursive descenrs parsers are not linear. They are generally O(n^2) and can even can go exponential with some grammars if written naively. It can be pretty easy to do adverserival attacks on most naive descent parser and bring it to its knees. Packrat parser [^1] are linear, but they are by no means "trivial 200 lines" type of parsers. [^1]: https://arxiv.org/abs/cs/0603077 https://arxiv.org/abs/cs/0603077

bregma 2mo ago

I don't think it is difficult to accept that fundamentals should be taught. We spend years learning basic arithmetic like the addition of integers. You could very well argue that there is no need for that either because everyone has a calculator app on their phone. This is how dark ages begin.

sacado2 2mo ago
It drives me crazy how so many people (of all ages) can't do basic math in their head, at least approximately. You need it constantly and it's so much faster than picking up your phone, starting the app, and typing in the operation. I'm so glad my teachers back in the 80s and 90s told me "you won't always have a calculator in your pocket". They were wrong (I do have one) but they were right (it's not always convenient to rely on a calculator).

nly 2mo ago

It's "fine" is you ignore adversarial situations. If someone is taking malicious stabs at your API then you have a problem

simonask 2mo ago
Yeah, absolutely. I would be worried about a JSON parser facing the internet that had these kinds of problems, for example. But it's only the very first in a long line of potential vulnerabilities such a system has to consider. What good is a perfect linear-time constant-space parser if the next thing the system does is to allocate hundreds of megabytes of objects representing some deserialized data structure? The parser is usually the least interesting part.