Subj : Re: Compiler and an interpreter To : comp.programming From : Rob Thorpe Date : Fri Aug 05 2005 11:48 am Jon Harrop wrote: > 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. I don't think it's particularly nice either. Whether it's idiomatic is a matter of opinion. Some C++ programmer I've met would do it with transform, others would prefer the iteration. Some would use a C like loop. > >> 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. Yes, that's what I mean. > > 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. Most programmers don't see it that way though, most I've met only know two or three languages and don't want to learn more. Programmers as a group have not taken the time to learn high-level languages, and I don't think they ever will. This means if you want to maintain a program in an obscure language, even a good one, then you find you can't. I write in C when I want to collaborate with other programmers. I sometimes write little bits of code for work my work. I write them in C, if I wrote them in anything other than C or Visual Basic then no-one could maintain them if I left. This is very often the situation. For example, could anyone from Wolfram research maintain your Mathematica implementation after you left? > >> 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. Interesting, I didn't know that. > > > > 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. I'm not sure it would be that complex, but it would certainly be more complex. > > * 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. Interesting, I'm surprised it wins on runtime as well as lines of code. > > 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. I would still say that were proper commenting done the difference would be much smaller. The Ocaml ray-tracer #2 is 57 lines long, and C++ 90 lines long. Lets say 70 lines of comments must be added, a reasonable number given the complexity of the algorithms. Then we have 127 lines of OCaml, and 160 lines of C++, the relative difference is less. Frequently I've picked a slightly more complex way to solve a problem over a concise one; because *explaining* the concise one would take more comments. > Incidentally, someone has written a Lisp implementation that is 500x slower > than the OCaml and almost twice as long. :-) Really, I'm not surprised it's slower, but I'm surprised it's longer. > >> > >> 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. Wow you must deal with some complex problems. .