Re: parser

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?

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.

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?

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

Wirth was on the list.

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.

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.

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.

(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.

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%.

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.

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.

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

Relevant Pages

  • Re: parser
    ... be more general than just being 'Common Lisp'... ... lots of brittle glue code and crap to marshall between the respective ... So you have only used languages that require you to write FFI code by ... Market share is a useful measure if you want to make money. ...
    (comp.programming)
  • Re: 98.6% DNA and Evolutionary Logic
    ... Humans are related to *all living things on Earth, ... stretches of DNA, charting a nested hierarchy. ... Some people believe that all languages are related by common ...
    (talk.origins)
  • 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: LC53 statistics
    ... Forth's wave of popularity was in the ... decline, because it froze Forth into an obsolete implementation model just when 32-bit processors entered the market, in addition to introducing changes that alienated a lot of Forth users. ... In fact, Forth94 was a major factor in enabling Forth to remain a competitive niche language, by adding the legitimacy of an internationally-recognized standard. ... On technical grounds, by eliminating implementation specifications Forth94 enabled the outburst of fast, optimized systems that are very competitive on a performance basis with other languages on the market. ...
    (comp.lang.forth)