Re: [Caml-list] productivity improvement

[Eray Ozkural <erayo@cs.bilkent.edu.tr>]

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 <typename _Expression> template <typename RHS_Gen_Expr>
Gen_Expr< Array_Add_Expression<_Expression,
  typename Object_Traits<RHS_Gen_Expr>::Expression> >
Gen_Expr<_Expression>::operator+ (const RHS_Gen_Expr& gen_right)
{
  typedef typename Object_Traits<RHS_Gen_Expr>::Expression RHS;
  typedef Array_Add_Expression<Expression,
    typename Object_Traits<RHS_Gen_Expr>::Expression> Add_Expression;
  typedef Gen_Expr<Add_Expression> Gen_Add;

  RHS right = Object_Traits<RHS_Gen_Expr>::reference
    (const_cast<RHS_Gen_Expr&>(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 <erayo@cs.bilkent.edu.tr>
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