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

[John Cowan <cowan@ccil.org>]

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

Very probably. But under pressure I went with what I knew I could get
right.  In hindsight it was like one of those non-quantitative
multiple-choice tests where you have to figure out not the correct answer
but the answer that the test author is most likely to believe to be correct.

On Mon, Mar 10, 2025, 4:49 PM Bakul Shah <bakul@iitbombay.org> wrote:

> Perhaps the interviewer was looking for something dumb like the following
> and not a full RD parser?
>
> int count = 0;
> while (*cp) {
>         char c = *cp++;
>         count += c == '(' ? 1 : c == ')' ? -1 : 0;
>         if (count < 0) return -1; // FAIL: one too many )
> }
> if (count > 0) return -1; // FAIL: too many (
> return 0; // SUCCESS
>
> Though this will fall apart if you also want to also balance braces &/or
> brackets and must catch invalid cases like "(..[..)..]"!
>
> > On Mar 10, 2025, at 8:19 AM, John Cowan <cowan@ccil.org> wrote:
> >
> > I was working at the whiteboard during a job interview once. I had been
> asked to write a function to report if its input had balanced parentheses.
> No problem: I wrote an RD parser in Python (which I prefer for
> whiteboarding) to detect balance and return True if the parse was
> successful and False if EOF was reached.
> >
> > I was starting to write some tests when the interviewer interrupted me.
> >
> > "What is that?"
> >
> > "It's a recursive descent parser. It detects if the input is
> well-formed."
> >
> > Blank look.
> >
> > I started to walk him through the code.
> >
> > He interrupted me. "Excuse me, I'll be back in a few minutes."
> >
> > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the
> recruiter will get back to you." That's the last I hear from them.
>
>

[-- Attachment #2: Type: text/html, Size: 2339 bytes --]