Re: Y Store now C++

[Ken Anderson <address@hidden>]

This story depresses me also.

I believe that  domain specific languages are a good thing.
Especially if users can make sense of it, as in your case.
My experience from common lisp is that an application can have several minilanguages in it.
Such languages can be implemented in a relatively tiny amount of code, in some languages, at least, and generate a substantial pile of code in the base language.Olin Shiver's talk at LL1 which described an awk  implementation in scheme is a good example of how small an implementation can be.

In your case, what actually got recoded in Java?  Was it the language implementation, or was the language obliterated and everything was written in Java?  Things like relative lines of code might provide interesting statistics.

At 08:14 AM 2/26/2003 -0700, Jerry Jackson wrote:


>John Morrison wrote:
>
>>On Tuesday 25 February 2003 10:04 am, Sundar Narasimhan wrote:
>>
>>>Most of them suggested that they'd either been told to learn it by
>>[ what *they* said -- snip snip ]
>>One of our sales guys once shocked me by saying that while it may be
>>true that salespeople lie, they do not lie nearly as much as customers
>>do.  His point was that customers do not *deliberately* lie, but they
>>often do not understand what is really causing their pain, in much the
>>same way a patient "lies" to his doctor.
>
>
>I had a very direct experience of that on my last job.  We were attempting to help insurance companies do rating and risk assessment. They had shown us several of their rating methodologies and claimed that they had the following problem:  Actuaries did not have enough insight into and control over the implementation of their methodologies.  They wanted to be able to write the implementations themselves.  We looked at their methodologies and determined that they could be directly translated into a suitable functional language.  We proceeded to implement said language with much input from the customer.  It was actually very nice with built-in database access, good sequence support (which was crucial for mapping their methodologies directly), and a (IMHO) novel approach to dealing with parameters that changed by region.
>
>We implemented one of their simpler methodologies in this language and showed them the result without telling them what it was.  The actuaries said things like:  "Hey, I can READ that!" and "Look!  That's our <mumble> methodology".  They were highly pleased.
>
>As it turned out, actuaries didn't really want to write code.  They considered it beneath them.
>
>The rest of the story bears on the larger topic:
>
>We thought, "Okay, the actuaries don't want to write code but this will still allow us to produce more understandable and reliable rating calculators". -- and in fact, it did.  The people who implemented the rating calculators claimed drastically increased productivity and a better quality product.  The actuaries could _read_ the resulting methodologies which greatly reduced the usual QA cycle.  Everything was peachy.
>
>Until... one of our competitors started telling the customer that they were becoming dangerously dependent on us.  If we failed, they'd be stuck with this code in a "proprietary language".  Plus, they could never hire anyone to write in this language.  Etc., etc.
>
>So, they payed through the nose to translate their applications to Java, even though we were willing to put all source code in escrow in case we failed and they clearly could get people to write the code as they were already doing so with people who had no particular applicable (or applicative :-) background.
>
>All in all, a very depressing experience.
>
>--Jerry