Prev: Good REST Client
Next: Unable to read after commit () with JPA
From: Tom Anderson on 14 May 2010 16:29
On Fri, 14 May 2010, Stefan Ram wrote:

> Arne Vajh?j <arne(a)vajhoej.dk> writes:
>> It is not possible to evaluate the complexity based on the
>> information given.
>
> customer: Could you write a parser for us?
> I: Ok, just send me the grammar.
> customer: The what?
> I: Some kind of EBNF or so.
> customer: Well, I can't write EBNF. Could you write the grammar, too?
> We'll send you some examples of the language.
> I: Ok.
> (time passes.)
> I: So here is the grammar. You just need to read it and sign this
> confirmation that it really describes the language you want me
> to write the parser for, then I can go on and write the actual parser.
> customer: But I can't read EBNF!

You write the parser, ship it to them, charge them for maintenance when it
breaks, and tell the anecdote afterwards on usenet"

tom

--
inspired by forty-rod whiskey
From: markspace on 14 May 2010 17:19
Lew wrote:

>
> The client should not sign off on the implementation, e.g., the parsing
> grammar. The client should sign off on the behavior, within the
> universe of discourse of their business, e.g., that the business
> transaction confers the proper information/cash/results.


Well, I agree, but how do you get the client to understand what it is
they are actually getting?

At this point you might have to write a users' manual for the product,
which should contain examples of the config file and how it works, with
some do's an don't's. That might satisfy the customer, with out
specifying the grammar. But this sort of "examples" is what I was
trying to get at in the post you replied to.
From: Tech Id on 23 May 2010 14:40
I tried my hands on JavaCC after fiddling with some crashes on ANTLR
And it worked really well.

Thanks to an Eclipse plug-in, My work is pertty much done!
First  |  Prev  | 
Pages: 1 2 3
Prev: Good REST Client
Next: Unable to read after commit () with JPA