Re: Compiler and an interpreter

In article <42f1e845$0$24015$ed2619ec@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
usenet@xxxxxxxxxxxxxx says...
> Gerry Quinn wrote:

> >> > If you get 13 lines to make a copy of a list of ints with each replaced
> >> > by the larger of 5 and the value in the original array (which I assume
> >> > you are doing), you must be including curly brackets and various
> >> > standard includes.
> >>
> >> Those are necessary.
> >
> > But they will not increase as the problem gets more complicated.
>
> No. Witness the dozens of curly braces in my slightly longer example.

I meant the includes. But a curly brackets is not really equivalent to
a typical "line of code" anyway.

> >> Those 4-lines are the equivalent of "List.map (max 5)", except that the
> >> OCaml is more general and can be reused.
> >
> > Either takes seconds to write.
>
> As programs get bigger, I'd rather write less code.

LOC is a poor metric for most purposes - it's reciprocal is equally
poor. The bottom line, in any case, is that typing speed is not a
bottleneck for most programmers.

> >> Are you going to say that your 4 lines of C++ are more comprehensible
> >> than the 16 characters of OCaml?
> >
> > To many here, they will be. I certainly had to guess from context what
> > you were trying to do. There is a certain vagueness attached as you
> > introduced what seems to be a specific spelled-out list (why not a more
> > efficient array, since elsewhere you talk about efficiency?)
>
> Arrays are not more efficient than lists.

Sometimes they are more efficient, sometimes they are less so. Arrays
(at least in C++) use contiguous regions of memory to store data - this
means the total memory usage is smaller and the locality of reference
is likely to be better. Lists, on the other hand, can use memory in
smaller pieces. These are in addition to any questions about how the
arrays are accessed. In the case in question, where all elements must
be accessed in any order, the array should be slightly more efficient
because the location of the next element is easier to calculate - but
there's not much in it.

In typical desktop PCs, it is said that arrays can sometimes win out
over lists even when there are insertion and deletion operations,
because of the better locality of reference.

> > and then apparently modified it, which seems futile.
>
> My code doesn't modify the list.

My mistake, so. In any case, modifying it in place is equally easy in
C++.

> > I have doubts whether set theoretic operations in STL are designed, or
> > at least implemented, for efficiency. Certainly if I wanted to write
> > an efficient program in the sphere referred to, I would carefully
> > consider my choice of data structures.
>
> You should study the STL...

Look what it did to you! Seriously, by your own account your excessive
respect for arcane STL features eventually resulted in your abandonment
of the language.

Certainly, I'll look at the STL, or any library, to see if it has what
I need. But efficient code requires a certain amount of attention to
the computer's needs also.

> Perhaps if you give some examples of applications that you believe FPLs are
> poorly suited to?

Computer games would be a good example.

> >> > I don't believe your benchmarks are valid.
> >>
> >> These aren't benchmarks, they are real programs.
> >
> > You present them as if they are benchmarks, IMO.
>
> Yes. Why do you think these real-world performance-critical programs are
> "invalid" as benchmarks?

Because you appear to use unsuitable methodologies in your C++
versions.

> >> That wasn't a "complex mathematical" formula. It was just a few set
> >> unions and differences. For really complicate formulae, OCaml will be
> >> relatively much better.
> >
> > It's complex by comparison with most of the formulae used in the vast
> > bulk of computer programming.
>
> I don't know what you think constitutes the "vast bulk of computer
> programming" but you'll find substantially more complicated algorithms and
> data structures in graphics, databases, games and so on. Most of these
> would be more easily and efficiently coded in OCaml than C++.

There may well be complex algorithms implemented here and there in all
sorts of software, but the bulk of most programs consists of simple
structures, marshalling of resources, user interfaces etc.

- Gerry Quinn




.

Relevant Pages

  • Re: RAD vs. performance
    ... arrays and lists are iterable containers which, while correct, applies to ... the optimisation phase. ... trade-off in the situations where this abstraction is useful but I think ...
    (comp.lang.misc)
  • FAQ 4.39 What is the difference between a list and an array?
    ... This message is one of several periodic postings to comp.lang.perl.misc ... from the documentation provided with Perl. ... Subroutines are passed and return lists, ... context, you initialize arrays with lists, and you foreachacross a ...
    (comp.lang.perl.misc)
  • FAQ 4.39 What is the difference between a list and an array?
    ... This message is one of several periodic postings to comp.lang.perl.misc ... from the documentation provided with Perl. ... Subroutines are passed and return lists, ... context, you initialize arrays with lists, and you foreachacross a ...
    (comp.lang.perl.misc)
  • FAQ 4.39 What is the difference between a list and an array?
    ... This message is one of several periodic postings to comp.lang.perl.misc ... from the documentation provided with Perl. ... Subroutines are passed and return lists, ... context, you initialize arrays with lists, and you foreachacross a ...
    (comp.lang.perl.misc)
  • FAQ 4.39 What is the difference between a list and an array?
    ... This message is one of several periodic postings to comp.lang.perl.misc ... from the documentation provided with Perl. ... Subroutines are passed and return lists, ... context, you initialize arrays with lists, and you foreachacross a ...
    (comp.lang.perl.misc)