|
When you inherit project and open it up for the first time, look in References and see System.Data.OracleClient.
![Elephant | [mastadon]](https://www.codeproject.com/script/Forums/Images/elephant.gif) me.
|
|
|
|
|
I feel your pain!
Technician
1. A person that fixes stuff you can't.
2. One who does precision guesswork based on unreliable data provided by those of questionable knowledge.
JaxCoder.com
|
|
|
|
|
Early morning, caffeine deficient, juxtaposed with your post below, I read that as
Mike Hankey wrote: I feel your paint
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I drink your watercolors 
«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
|
|
|
|
|
AND YOU JUST_KNOW YOU are going to enjoy all those underscores.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Could be worse, it could've been VB6.
|
|
|
|
|
It is worse. It's a VB.NET project that started life as a VB6 project and was run through the conversion tool, and then you add 3rd party conversion tools to it and you get an ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) ing nightmare.
|
|
|
|
|
I was offered a job as an Oracle DBA.
Luckily, they asked if I would be interested in a different position, so of course I said Yes. Doing front-end web work for something.
But what the heck is "Groovy"? Well, at least it's not Oracle.
|
|
|
|
|
GenJerDan wrote: they asked if I would be interested in a different position
Based on comments from an Oracle app developer I know, at least with something else they'd offer lube.
Software Zen: delete this;
|
|
|
|
|
I work on an Oracle based system and yep it's horrible.
After the current job I will never work with an Oracle database again if I can help it.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I once applied for a job in the military.
"Your resume says you're in IT so we have two available positions, you can become an Oracle DBA or we can test new torture methods on you."
"I'll take the torture methods, please."
They then presented me with an Oracle database 
|
|
|
|
|
Wimp.
You need to embrace it.
|
|
|
|
|
it didn't work!
Technician
1. A person that fixes stuff you can't.
2. One who does precision guesswork based on unreliable data provided by those of questionable knowledge.
JaxCoder.com
|
|
|
|
|
|
/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). 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
