From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-09-15 02:36:05
Dean Michael Berris wrote:
> Hi Rene,
> On 9/15/06, Rene Rivera <grafikrobot_at_[hidden]> 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
[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
[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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk