Dean Michael Berris wrote:
Hi Rene,
On 9/15/06, Rene Rivera <grafikrobot@gmail.com> wrote:
Sorry, but I'm going to be rather uncharacteristically apolitically frank...
It's alright. :-)
I thought it was going to be my last post... But these things have a way a barreling out of of control ;-)
Yea... Looks as bad as I feared.
Unfortunately, the implementation might need some work (aesthetically, or even code-wise).
Didn't look at it. I think the utility and hence design of the user interface is the item in question.
However, if the judgement is about the "value(...).should.equal(...)", then I'd like to think it might be a matter of preference. :-D
I'm going to disagree with a perspective sensitive simulation... [I put my programmer hat on being told by a manager that I need to understand and possibly write these things.] It looks like some English words trying to define a logical expression. How unnatural, and prone to errors. I'd rather write those as real expressions. [I put my customer hat on being told by the manager of a company I hired that this is what programmers need to write the software I'm paying for. And not only that I'm bound to do it because it's in the contract.] Hm, looks like English, this should be easy. Wait, what are all those periods. I only put periods at the end of sentences. I'll just write them the correct way. I talk to the manager, hand her the specs. Later she gets back to me that there are problems with the specs and the programmers can't use them. What do you mean they can't use them, it's perfectly valid English descriptions. What am I paying you for? Make the programmers read my specs. [I put on my manager hat (note, I can do all these hats because I have been all those, sometimes two of those at once)] OK, we'll use the specs. I go and talk to the programmers... These are the only specs we are getting so you must use them. What can we do? [Back to programmer] Well we can parse and translate them into our internal testing specs. That will take 3 months to write a barely tested NLP and KBR that we can use to translate. Or we can write a cheesy regex parser that we'll have to tweek until it works. That might take a month. Or we can have one of our junior programmers read the specs and write corresponding test code, and abandon the whole automated customer spec system. That will take a few days. [Back to manager] OK, fine, get the junior programmer working on it ASAP. [Back to programmer] Hey junior programmer... Translate these into code we can understand. You have 2 days. ...Junior programmer goes and works to death for 24 of the next 48 hours. But only gets paid for 16 of those as a salaried employee. :-(
Maybe it might need getting used to... :-)
The human brain has this stubborn ability to directly map things it gets used to, to the singular generic case. Hence you'll end up writing natural English in no time flat.
Staring at a whole slew of ASSERT_EQUAL or similar "un-englishlike" constructs along with the C++ constructs gets tiring at times -- much like beer, it's an acquired taste and it gets boring at times. After all, BDD is an alternative or a "language shift" to the traditional TDD approach of "Unit Testing".
Sure, using the same tool over and over again can get really boring. But it's invariably a bad idea, no matter how novel it might seem at the time, to use a pencil to hammer in a nine inch nail.
Yeah... But using language that's closer to "natural language" or in this case, English, makes the code/specification readable IMO.
But you at minimum understand C++. Try the example you posted and hand it over to a nearby secretary, admin assistant, mail clerk, artist, marketing vp, etc. and ask them to explain it.
If not for the possibility of programmatically generating programmatic specifications (specification metaprogramming?) to even a considerably readable implementation in C++
One of the hallmarks of knowledge based reasoning AI system is the separation of expert domains with appropriate translation and interpretation between the human knowledge and its programmatic equivalent. At each of those rifts of expertise there is either a very complex knowledge understanding system that does, if you are lucky, 25% of the job of going from domain to program. Or; You have a highly qualified human multi-domain translation expert that will do 100% of the translation job with a magnitude better efficiency for 1% of the cost of the programmatic translator.
, BDD is Yet Another Testing And Software Engineering Paradigm.
I think you mean "Testing And Software Engineering Method" ;-) Note, if it wasn't clear enough. My point is that you can achieve much better results with human documentation for considerably lower investment than what you would be able to achieve with such COBOL like program spec languages. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo