Re: Y Store now C++

[address@hidden]

The way to have domain-specific languages be more
accepted in industry is probably to avoid calling
them "languages".  Do not say "We are using Fraz
instead of Java because it is better than Java."
Build Fraz in Java, or in C++ or whatever, and
then say that Fraz is a representation, or something
like that, avoiding the l-word.
> 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
>