Subj : Re: Compiler and an interpreter To : comp.programming From : Jon Harrop Date : Sat Aug 06 2005 02:18 am Rob Thorpe wrote: >> 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. I would use iteration and not the pseudo-functional approach (e.g. transform) offered by the STL. C++ simply isn't expressive enough to support functional programming (and many other paradigms) in a way that is productive. >> 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. Yes. The main advantage of knowing OCaml is that you can automate the jobs of 50 programmers who only know C. Indeed, if you have to, you can write OCaml programs that generate C code... > This means if you want to maintain a program in an obscure language, > even a good one, then you find you can't. Yes. This inertia means that obscure programming languages like OCaml are only suitable for the most difficult problems in industry. Until a language like OCaml becomes mainstream, I wouldn't advocate that large companies use it for general work. However, there is a lot of work that is specialised and difficult enough that languages like OCaml are a huge benefit. Mathematica is an obvious example. > 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. I appreciate that. > This is very often the situation. For example, could anyone from > Wolfram research maintain your Mathematica implementation after you > left? Oh yes, I don't think the relevant guys at Wolfram Research would have any problems learning OCaml. Indeed, they would find it to be so much better than what they're used to (their application is exactly ML's strongest point) that they would surely lap it up. :-) >> 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. Yes, there is no question that the STL was designed for efficiency. >> 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. Look at the implementation of RB trees with set-theoretic operations in the STL: $ wc stl_tree.h stl_set.h stl_algobase.hstl_alloc.h stl_construct.h stl_function.h 1333 4231 43561 stl_tree.h 216 815 7709 stl_set.h 526 1821 17657 stl_algobase.h 1057 3923 33856 stl_alloc.h 90 355 2704 stl_construct.h 700 2578 22197 stl_function.h 3922 13723 127684 total That's 4kLOC that are pulled in and you're going to be specialising it. Frankly, this kind of code is so error-prone in C++ that is simply isn't worth trying to improve upon the generic STL implementation. Incidentally, OCaml's Set module is 330LOC. 8-) >> 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. The C++ does have more potential for optimisation than the OCaml. Specifically, if an infinitely knowledgeable programmer spent an infinite amount of time optimising the C++ and the OCaml for a specific platform, the C++ would be fastest. However, that isn't very interesting in practice... >> > 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. But you've glossed over the fact that the C++ implementation has to be significantly more obfuscated because C++ isn't as expressive as OCaml. For example, are you really going to say that the following OCaml: type scene = Sphere of vec3 * float | Group of sphere * scene list requires the same volume of comments as the equivalent C++: struct Scene { virtual ~Scene() {}; }; struct Sphere : public Scene { Vec center; double radius; Sphere(Vec c, double r) : center(c), radius(r) {} ~Sphere() {} }; typedef list Scenes; struct Group : public Scene { Sphere bound; Scenes child; Group(Sphere b, Scenes c) : bound(b), child(c) {} ~Group() { for (Scenes::const_iterator it=child.begin(); it!=child.end(); ++it) delete *it; } ? > 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. Yes, I've done that. >> 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. I'm surprised that you're surprised it's longer. I thought OCaml was far more succinct than Lisp. >> 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. Well, yes. My programs usually have aspects that have never been done before (AFAIK). For me, that is very motivating. -- Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com .