From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA22781; Thu, 17 Oct 2002 10:38:01 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA22657 for caml-list@pauillac.inria.fr; Thu, 17 Oct 2002 10:38:00 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA14602 for ; Thu, 17 Oct 2002 02:16:20 +0200 (MET DST) Received: from mail.interaktif.net.tr ([62.248.102.120]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g9H0GI523927; Thu, 17 Oct 2002 02:16:18 +0200 (MET DST) Received: from abn166-176.ank-avrupa-ports.kablonet.net.tr (unknown [195.174.166.176]) by mail.interaktif.net.tr (Postfix) with ESMTP id 0313B1E660; Thu, 17 Oct 2002 03:13:27 +0300 (EEST) From: Eray Ozkural Organization: Bilkent University CS Dept. To: Pal-Kristian Engstad , Xavier Leroy , Oleg Subject: Re: [Caml-list] productivity improvement Date: Thu, 17 Oct 2002 03:12:27 +0300 User-Agent: KMail/1.4.5 Cc: Emmanuel Renieris , caml-list@inria.fr References: <20020716172916.4903.qmail@web10702.mail.yahoo.com> <200210151224.47272.erayo@cs.bilkent.edu.tr> <200210151147.36156.engstad@naughtydog.com> In-Reply-To: <200210151147.36156.engstad@naughtydog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200210170312.27133.erayo@cs.bilkent.edu.tr> Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Tuesday 15 October 2002 21:47, Pal-Kristian Engstad wrote: > > > That code I think went down from about 2500 lines to 500 lines which > > isn't bad. To attain that kind of improvement, you need a change in > > style. The C program apparently used lots of text I/O to transfer and > > store data between modules. The Haskell program didn't have to. > > That's strange. How could the Haskell program not have to do IO? > Like many UNIX C codes, each module in the C code was a separate executable storing intermediate results in ASCII files. That is a good programming style for not so simple C codes because: 1) C is terribly hard to debug 2) C programs are easy to break 3) It's very hard to implement complex/dynamic data structures in C And so on However, in a functional language I can afford to implement those data structures to handle everything in-core. The reliability of the language helps me to keep it relatively bug-free, and it's very easy to write functions that accomplish complex tasks. I tried to do the same with C++ but it would result in meaningless container classes (like for each session, stock, stock market, etc.) and glue code. That kind of thing is what I mean by change of style. If you do not change style, your program is not going to differ too much. You have to use the powerful features of the functional language to your advantage for gaining the edge. It's pretty much like the old arguments about C vs. C++. Well you can write code that is just like C code in C++. There isn't much point in doing so, and still you can see incompetent programmers going all printf, atoi and int a[100] in C++. You can even write assembly-style code in C++, but what purpose would that serve? So if you're not using higher-order functions, recursive types, etc. in your program, your program is *not* really functional.[+] It is often quite *impossible* to translate a program in functional style to C++ without significant loss of quality and performance, ie. your code size is going to blow up to a factor of 2-3 at least and performance is going to suck.[|] In addition, I shouldn't have to mention how useful an interpreter can be while developing complex applications like machine learning. With C++, you would cringe at never-ending compilations and SIGSEGVs... With your ultra-hip functional language you don't work that way. Talk about productivity. After all, we all know how the "functional paradigm" was addressed in the C++ standard: by a severely deficient imitation of (1st class?) functions through templates. Sorry, but I can't afford my code to look anywhere similar to STL. Using the standard lib for those data structures and algorithms may be okay, but writing something like STL itself is a big NO-NO. I think to understand how futile that exercise is, every C++ programmer must undertake an impossible-in-C++ project. Here is one for you: write a general purpose parallel array library with syntax similar to that of blitz, should implement efficient parallel algorithms for a large class of topologies. That was the project which led me to conclude that C++ was *not* fitting for generic programming.... Nobody should ever write code like the following snippet, yet I suspect intermediate C++ programmers would be delighted by the looks of it: "Wow it looks just like part of the standard library" How great! What a big bunch of crap! Just imagine you are trying to add a new feature to this kind of code, you have to change like hundreds of template parameters, signatures and functions.... That project was a difficult piece of C++ trickery after which I concluded that C++ was not the right language to implement such a system. I also wrote that down in the report. There was simply no way it could be done without making it an enormous portion of spaghetti. (Supporting distributions/alignments a la HPF was virtually impossible) There are many academic projects in the field of scientific computing with similar goals. Just try to compile them or understand a bit of the implementation. -------------------------------- awful C++ code..... template template Gen_Expr< Array_Add_Expression<_Expression, typename Object_Traits::Expression> > Gen_Expr<_Expression>::operator+ (const RHS_Gen_Expr& gen_right) { typedef typename Object_Traits::Expression RHS; typedef Array_Add_Expression::Expression> Add_Expression; typedef Gen_Expr Gen_Add; RHS right = Object_Traits::reference (const_cast(gen_right)); // nlog << node_str << *this << " + " << right << endl; Gen_Add return_expr(Add_Expression(expression, right)); return return_expr; } -------------------------------------------------------- [+] You don't really have to use lists everywhere, that's LISP not ocaml. [|] Don't bring up ghc's poor performance in this discussion, think ocaml -- Eray Ozkural Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners