Re: parser


"Jon Harrop" <jon@xxxxxxxxxxxxxxxxx> wrote in message
news:W9GdnfcjOKz8tEfVnZ2dnUVZ8s3inZ2d@xxxxxxxxx
cr88192 wrote:
"Jon Harrop" <jon@xxxxxxxxxxxxxxxxx> wrote in message
news:VtednWHnwMFA2EnVnZ2dnUVZ8jSdnZ2d@xxxxxxxxx
I remember a while back (years ago) when I tried integrating a script
VM
(in this case, Scheme) in the Quake1 engine. this didn't turn out so
well (a horrible PITA to patch over the engines' machinery, ...) so,
eventually
I dropped the project.

Scheme was not one of the listed languages ("LISP/SML/ML and Wirth").

Scheme is usually considered a variant of LISP, if one considers LISP to
be more general than just being 'Common Lisp'...

Ok.

combine this with numerous latter attempts, and difficulties/hassles
with, integrating high-level VMs with a C codebase (the pain of
stubbing
over type interfaces, native functions accessible, ...).

Those are not specific examples.

you expect specific examples for this sort of experience?...

Yes, of course.

"does not integrate well" can be taken as an analogous to "to make it
work
one has to go through a bunch of hassles", of which "me having to write
lots of brittle glue code and crap to marshall between the respective
type
systems, and may have to rewrite it whenever crap changes" can be
considered as a general statement of experience.

now, maybe some people like writing brittle glue code, but others do
not...

now, maybe it is all managable so long as "someone else" is doing all
this
crap, but when one is themselves the one doing it (for example, because
it
is their codebase), it is not quite so pretty...

So you have only used languages that require you to write FFI code by
hand?


I have used ones where one writes out a plain declaration with some subset
of the languages' type systems, but one quickly comes across a much bigger
issue: this is only very rarely sufficient.

so, most often, to wrap a function which accepts any complex data, ... it is
needed to write wrapper code.


and, from what I see, even the big commercial efforts often require the
same sort of process, and face many of the same issues.

You have still not cited a single example to backup your claim that
these
languages do not "integrate well with existing codebases".

how about the existence of tools like SWIG.
now take note of how crapily SWIG works in many cases...

The presence of awful free software says nothing about anything else.


SWIG is generally considered the "upper end" as far as most "automatic" FFIs
go.


can you explain why some people went and rewrote zlib in C#?...
what of libjpeg?...

Educational value, licensing issues, performance studies, safety or any
of a number of other reasons. So that does nothing to substantiate your
claim that Lisps, MLs and Wirth cannot integrate well with the OS and
common system libraries.

enough examples exist for those who have actually dealt with these
issues.

If there are so many examples, why are you unable to cite a single one?


I don't know as much of other peoples' experience, I mostly cite my own
experience.

that people can make crap work if they try is not the issue, it is that it
does not typically work on its own, or in a particularly clean or
transparent manner. this has actually been my set of goals, namely that
nearly all of the interfacing can take place on its own, without the user or
anyone else having to do anything "special" for the implementation to figure
it out.


now, where did 'Wirth' come from (it was not in prior context from what I
remember)?...

Wirth was on the list.


ok, it had fallen out of context and I had not remembered it.


The Bigarray.Array1.map_file function in the OCaml standard library is
an
obvious counter example: it uses Unix calls to memory map a file and
make
it accessible as a flat array ideal for compression etc.

potentially, I would have to look into the level of which it handles
pointers though...
things are not so pretty if one doesn't have good pointer operations...

Pointers do not exist in modern languages.


however, they are one of the more important and useful features in many
cases for data manipulation.
many things are far more painful if one lacks them...


or, maybe you mean:
it is a big byte array and people have to get/set values as indices?...
it works, but is far from ideal.

An array of any dimension with any element type.


this is, not much better, given that most data is internally far more
structured than flat arrays of this sort...
one then will then likely have to individually pick values out of the data,
such as reading individual items out of bytes and transferring them to some
complex "high-level" type.


We have found ML code (OCaml and F#) to be around 10x cheaper to
maintain than C++ code. Many other companies have come to the same
conclusion and, indeed, this is precisely why Microsoft are
productizing F#.

they produce F# for people who are willing to use it.
however, not everyone will use such a language.

Sure, but F# will almost certainly gain 10% market share, i.e. more than
C++.

you mean, because C++ can't gain too much more?...

Gain much more? C++ has been in decline for years and that is not going to
change.


it is still going fairly strong, FWIW...


(ok, apart from maybe C and Java dropping).
maybe, but this is not a very useful measure.

Market share is a useful measure if you want to make money.


and, can you give much evidence of languages like F# having much market
share, or even much potential of it?...

more so, what even is exactly this "market share" that keeps being talked
about?...


it is like saying, "Windows will invariably lose market share relative to
Linux", yes, because Windows can't gain that much more (apart from the
unlikely situation of nearly all other OS's falling into oblivion), but
instead can only really lose market.

Except that Windows has a stable >90% market share whereas C++ has a
rapidly
declining market share now down to only 16%.


this depends heavily on where you look as well...

different tables say different things, and many give it a much higher
ranking (typically, just behind Java).


keep in mind that a book will sell if it is about an uncommon
subject...

That is the exact opposite of what you just said.

"in" and "about" are very different relations.

one can readily sell books about all sorts of crap, and people will read
them.

but, no one can read the book if it is written in a language people don't
read (they see it, it is just incoherent symbols, not a whole lot of
reason to buy it).

People who buy my OCaml book do not already know OCaml. The code in my
book
is entirely OCaml. So the code must appear to them as "incoherent
symbols".
Yet the book is a great commercial success.

That is obviously a counter example.


no, the book is "about OCaml", and not "in OCaml", more so, humans are not
compilers, and so this claim does not hold.

rather, is the book in English, or is it in some obscure or classical
language (such as old english, classical greek, ?...).


newbie programmers would actually have to go through some effort to
go
and
copy/paste bits from other projects if they work in an uncommon
language,

Why would that be any more difficult in an uncommon language? Indeed,
I would say that it is vastly easier because the quality of code in
those languages is generally much higher than in C++.

but there is also far less code to copy from, and most people seeking
to
copy/paste, will go and search for code, and invariably find code in
these
common languages.

Common code is not good code.

but it is common, making it more useful.

Bad code is not useful.


common code is not necessarily bad code either.


we can note, for example, the rampant commonality of newbies copying and
pasting code fragments off the internet trying to make their apps work. that
they can find code fragments, is often of much greater use to them, than the
theoretical merits of the language itself.

of course, there are many other uses of common code besides this (such as
easing portability, ...).


--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u


.

Relevant Pages

  • Re: Object Oriented PHP vs Java
    ... type/interface inheritence, which is about subtyping ... only useful for 'rigidly-typed' languages like Java and C++ - which BTW ... Encapsulation largely predates OO and is of common use in procedural ... Polymorphism is also independant of OO, ...
    (comp.lang.php)
  • Re: Commonalities across synaesthetes
    ... particular uncommon colours? ... tend to pair with common colours. ... To be 'hard-wired' all languages would have to have the same ... of sparking over is systematically modified by environmental ...
    (uk.philosophy.humanism)
  • Re: parser
    ... be more general than just being 'Common Lisp'... ... So you have only used languages that require you to write FFI code by hand? ... because C++ can't gain too much more?... ... Market share is a useful measure if you want to make money. ...
    (comp.programming)
  • Re: Lisp an abstraction layer?
    ... > procedural) programming (nearly all common known languages), ... For example Common ... Lisp can perform logic programming via this route. ...
    (comp.lang.lisp)
  • Re: So it is true...
    ... >Is that only since Czechoslovakia split or was it common before? ... In the times of the old federal republic the languages were ... denominations were printed in Czech and half in Slovak. ...
    (sci.lang)