|
|
/ravi
|
|
|
|
|
I like how he just brushed it off.
|
|
|
|
|
|
Color me surprised, but that seems like a stroke of bad luck.
|
|
|
|
|
What a paintful disappointment!
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Please bring some garish color paint and tome thinner. Then we can load it inti my Super Soaker (TM) airbrush and have some fun.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
An LR parser works like this
Fetch = tokenFoo
Fetch = tokenBar
Fetch = tokenBaz
// parser recognizes those three in a row so it reduces to a rule
Foobar -> tokenFoo tokenBar tokenBaz
You don't get the rule to reduce to until after the tokens are read. You have no idea how many tokens it takes to resolve a rule until after the fact. Which is fine. Usually.
So to build a tree, you have to keep a stack, push any tokens fetched, and then whenever you reduce to a rule, you pop the tokens on the right hand side of the rule, and push a new token for the left hand side of the rule. Easy.
The trouble is when an error is encountered. You won't necessarily get the right number of tokens back
(the parser can actually handle this part, but the tree builder can't)
Fetch = tokenFoo
Fetch = error
Reduce = FooBar -> tokenFoo error ???
Ouch. I don't have enough tokens.
The trouble is, I don't know I don't have enough tokens until the stack is empty.
So basically, I can't even build trees from a shift reduce/LR parser if there are errors in the input.
This is BAD.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: This is BAD.
Why?
Do you want fail-fast or fault-tolerant?
|
|
|
|
|
Because one of the points of a parser generator is having both of those things.
*sigh*
It's not really complete without error recovery
Still, I was looking, and I see Gold Parser's parser doesn't do error recovery either.
It's not right though. It's just not right.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
*needless* *heedless* *hopeless* *headmess*
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Reading thru The Mythical Man Month and there are quite a few interesting items.
Gutless Estimating
Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion.
An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices --- wait or eat it raw. Software customers have had the same choices.
The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save --— burned in one part, raw in another.
Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers. But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineering.
It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.
Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on. The whole profession can only profit from sharing such data. Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.
I'm pretty sure that estimating hasn't changed at all since this was originally written (1982 or so). 
|
|
|
|
|
And like an omelette, you have to break a few eggs to get the job done. 
|
|
|
|
|
Marc Clifton wrote: And like an omelette, you have to break a few eggs to get the job done.
And just un-like an omelette, the software job is never, ever done
|
|
|
|
|
Quote: Alberto Einsteinious* Software is never complete, it is only released.
*fake quote (of course)-but it's still true. 
|
|
|
|
|
Surely you keep your omelette up to date with the latest frying pans and optional herbs and spices?
|
|
|
|
|
...and if you rush the chicken to produce eggs quicker, you'll end up with a burnt out chicken before long.
I'm sure plenty more valid analogies can be added. C'mon CP, don't let me down...
|
|
|
|
|
dandy72 wrote: I'm sure plenty more valid analogies can be added. C'mon CP, don't let me down..
PHB Wisdom: If the chicken has already crossed the road, then you no longer have to implement Agile.
|
|
|
|
|
raddevus wrote: If the chicken has already crossed the road, then you no longer have to implement Agile.
No, no, no - that's not how Agile™ works. The chicken stops every six inches while it walks across the road (these are 'sprints'). It verifies with the stakeholder (aka the farmer) at each point that he's getting what he wants, i.e. the chicken across the road. The farmer can adjust the chicken's route any time he likes.
Of course, none of the principals notice the traffic on the road...
Software Zen: delete this;
|
|
|
|
|
|
That's easy. Use git for source control so that nobody really understands what a 'commit' does.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: That's easy. Use git for source control so that nobody really understands what a 'commit' does.
Wow! You've obviously ascended into Management! 
|
|
|
|
|
Them's fightin' words! Put 'em up! 
Software Zen: delete this;
|
|
|
|
|
|
F***ing yes.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
