On Tue, 1 May 2018 09:40:34 +0100, The Natural Philosopher
 wrote:
> On 01/05/18 08:50, Andy Leighton wrote:
>> On Mon, 30 Apr 2018 21:56:23 +0100, The Natural Philosopher
 wrote:
>>> On 30/04/18 20:57, Andy Leighton wrote:
>>>> How does SQL map into machine code?
>>>
>>> Pretty badly.:-)
>>>
>>>
>>>> How does Prolog? Erlang? Haskell?
>>>
>>> Even worse....?
>>>
>>> Probably why they have never been used for anything important that I can
>>> think of...
>>
>> Really?
>>
>> SQL is used extensively.
>
> My last sentence wasn't reffering to SQL
>
>
>> Erlang was/is widely used in telephone exchanges
>> and mobile networks. I will admit that Prolog and Haskell haven't got wide
>> usage. But TBH many of the languages Gareth listed do not have wide
>> usage these days.
>>
> *shrug* my point exactly. For all their theoretical elegance, the
> language which most easily (if not 1:1) maps onto the underlying machine
> architecture, rather than mapping to and abstract computational concept
> that then has to be shoe-horned into assembler, is teh one that is the
> most popular.

Not my experience. Most projects choose languages because their
ecosystem of libraries and frameworks do a good job at supporting
their requirements. Also because it is quicker to develop certain
applications in certain languages.

> I have cionsiderable exposure to (My)SQL (alhtough not
> Oracle or any other heavyweight commercial implementation) and even here
> my experience proves my point. Anything more than the simplest of
> queries leads to performance issues which are solved by ignoring the
> elegant flexible features of the language and hard coding exactly what
> you are trying to do with the data ine.g.  C.

Maybe your experience with sql isn't as deep as you think. I have had years
of database experience both in the old days with dBase III style databses
(apps written in Clipper), and with various SQL and SQL-like (I started
with Ingres on 4.2bsd before it used SQL and before SQL was standardised)
and have used Postgres, mysql, MS-SQL, Sybase Anywhere, Sybase ASE,
and Oracle.

Yes it is easy to write non-performant queries and updates in sql, and
sql dialects. Some of that can be due to poor db design, but a lot is
due to poor knowledge. It is also IME possible to increase the
performance of some of those non-performant queries a thousand-fold.

> C sits nicely between  the overwight syntax and non portability of
> assembler, and teh ineffeicient and unintelligent langeuages of computer
> scientists, who instead of respecting the hardware upon which their code
> nust run, as COBOL, FORTRAN and B/BCPL/C did, instead ignore it in their
> search for symmetry elegance and presumably geek status, whils what they
> have implemented rumbles along overblown and overweight and bug filled.

Now you are trolling. I have written stuff in a number of assembly
languages, and in C and wouldn't say anything close to that.

--
Andy Leighton => andyl@azaal.plus.com
"We demand rigidly defined areas of doubt and uncertainty!"
   - Douglas Adams

--- SoupGate-Win32 v1.05