Re: Object-relational impedence
Date: Thu, 6 Mar 2008 19:12:20 +0100
On Thu, 6 Mar 2008 14:30:56 +0000, Eric wrote:
> On 2008-03-05, Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de> wrote:
>> On Wed, 5 Mar 2008 12:22:24 +0000, Eric wrote: >> >>> If you should not use multiple languages, there must be a universal >>> language. >> >> Yep, it is called a universal/general purpose programming language. >> >>> What is it, is it really universal _right now_, and if not, >> >> It is, there exist many of them.
> So any general purpose language will do, as long as I use only that? Do
> I have to use the same one for the next task?
Yes, but purpose is not the only criterion. For that matter, VB is a general purpose language.
>> The mistake you make is in a wrong presumption that "universal purpose" <=> >> "best possible."
> I presume no such thing.
> Any program can be written in any language, but particular combinations
> may be unwise. Why should I not choose the most appropriate language of
> those that are currently available to me?
Because it is bad engineering. Any possible local advantage will be consumed by multilingual impedance.
> If I bring in an existing API to do some part of the task, why should I
> care what it is written in as long as I can call it? If it would help me
> to create an additional abstraction layer (i.e. my own API), why should
> I not use the most appropriate tool for it?
Because it is software design / performance / maintenance nightmare.
> What language do you use,
> and what is your math library written in?
This is a poor example.
Firstly math libraries of elementary functions are more or less well defined, deeply studied, solid mathematical and CS background. The interfaces and implementations are stable. It is not my system, I don't program them.
Secondly, certainly I would like them rewritten in a language better than K&R C / FORTRAN IV. These languages have undefined numeric behavior in numerous cases. I prefer exceptions and interval computation based version. I would like flexible precision control, as well as fixed-point versions and dimensioned versions. Neither could be delivered in C/FORTRAN.
>>> when will it be and what should we do in the meantime? >> >> Not to develop pet domain-specific languages if the advantages of those are >> unclear. If you, say, wanted to create a declarative language based on >> inference, then that should be a universal purpose one.
> An API, or an abstraction layer, _is_ a domain-specific language. If it
> can be made easier to use by bolting a parser on to the front of it, why
> not do that?
Because handicraft is not engineering. Statistically this does not pay off.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Thu Mar 06 2008 - 19:12:20 CET