Subj : Re: Compiler and an interpreter To : comp.programming From : Jon Harrop Date : Thu Aug 04 2005 07:32 pm Rob Thorpe wrote: > Also, what Jon has written is something of a cliche. In lisp you would > write something like: > > (mapcar #'(lambda (x) (max x 5)) list) > > This improves understanding, because the programmer can recognise this > cliche and recall what it means without having to read all the code. > The mapcar idion above is frequent in lisp. > > I'm pretty sure you can do this in C++ anyway, with "transform". I already posted that, but Gerry didn't like it because it is Lisp-like C++: #include #include #include #include using namespace std; int mymax(int i, int j) { return max(i, j); } int main() { list l; for (int i=1; i<10; i++) l.push_back(i); transform(l.begin(), l.end(), l.begin(), bind1st(ptr_fun(mymax), 5)); copy(l.begin(), l.end(), ostream_iterator(cout, "\n")); return 0; } Of course, this C++ is hideously difficult to write and debug (IMHO). For example, it took me 15mins of STL-manual reading and Googling before I could get the "transform" line to compile. >> 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?) and then >> apparently modified it, which seems futile. I asume you wanted both >> the original and a copy but that's just a guess. > > I'd agree about that. There are two reasons:- > 1 Because C++ is a more well known language. > 2 Because the C++ involves iteration you can see > > 2. is really a sub-problem of 1, programmers of other langauges are > used iterations they can't see. If you mean that most programmers are used to seeing loops everywhere then I agree. However, that is only a result of common programming languages making it prohibitively difficult to factor out loops, e.g. into map, iter, fold. > 1. Is the crux of the problem. I would use functional languages if any > sizable number of other programmers knew them, but they don't. So > there are far fewer people able to maintain or improve my code. From my point of view, the data structures and algorithms (i.e. the task itself) is so much more complicated than the language it happens to be coded in that having to learn a new language isn't significant. >> 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. > > I have doubts if the STL was designed. > I'm also not sure about "set". The STL set implementation bundled with g++ (written by SGI) is based upon RB trees and goes into great detail about the complexities and efficiencies of algorithms. >> In any case, C++ is a general purpose language, not one designed for >> the translation of mathematical functions. Indeed, the tiny fraction >> of problems that consist largely of translating mathematical equations >> into programs likely constitutes a large part of the useful domain of >> functional languages. > > Most functional languages have been designed to be general purpose, > they target the same tasks as C++. OCaml -of which Jon is so fond- > certainly was. Historically, ML was designed for writing compilers and interpreters. OCaml has unquestionably inherited from ML (e.g. ocamlyacc and ocamllex) but OCaml has been developed so much in other ways (e.g. OO) that I can't think that anyone would object (pun intended) to OCaml being called a general purpose language. I'd be hard-pressed to think of any ways that OCaml is less capable than C++. Trivial bit-banging interfaces maybe. I really don't understand Gerry's aversion to shorter, simpler and faster code though. >> > > 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. > > For stuff like that shown above, either it's critical and has to be > fast, or it isn't and it doesn't and might as well be as clear as > possible. > > So, what would be really interesting to know is: > * Could one write a more concise C++ version, regardless of efficiency In C++, you would ditch sets and hash tables and just use arrays. However, the program would no longer terminate in our lifetime. > * Could one write a faster C++ version, regardless of conciseness Roll your own custom-made data structures. Performance could ~2x faster but it would take about a month of programming and the result would be well over 1,000LOC. > * Could both be done I don't think it can be made both faster and shorter. My ray tracer language comparison has already addressed this: http://www.ffconsultancy.com/free/ray_tracer/languages.html OCaml does vastly better than g++-compiled C++, of course. > It would also be interesting to see a comparison between versions that > have enough commentary in them to be readable. Most of my code is ~1/2 > comments (and even that often isn't enough). It would be interesting. However, this is highly subjective. In the case of the ray tracer, for example, the programs are so similar that comments will be insignificantly different between languages. Incidentally, someone has written a Lisp implementation that is 500x slower than the OCaml and almost twice as long. :-) >> > > I do accept that for the small subset of programming tasks that >> > > equate to implementing complex mathematical formulae, implementations >> > > that use >> > > functional languages will indeed tend to be more compact. For what >> > > that is worth. >> > >> > 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. > > It's not that complex, though it's certainly more complex than average. I'd say it the "nth_nn" function is simpler than the average function but the whole program is not simpler than the average program. > Perhaps one function in a twenty a programmer would have to write > would be that complex, I'd guess. Yes, I'd agree with that. -- Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com .