Slashdot Mirror

Okay... but here's my point: Every single example that shows how elegant Haskell and OCaml are uses lists. The 4-line Quicksort example for Haskell uses lists. All of the code that demonstrates easy reuse of functions and functions taken as arguments uses lists (like how easy it is to implement quite complicated algorithms using only map and filter, for example).

Or perhaps more correctly, "every single example that you've seen". For a real quick one, look at Jason Hickey's Intro to OCaml (pdf) and have a quick peek at his Red/Black tree implementation. Or even cooler (if you're into that sort of thing) is the ever famous One Day Compilers talk.

But what you're saying in #1 above is that in "production," speed-sensitive code, no one is using lists... this would mean that no one is using map, filter, or any other pieces of reusable primitive code. So, they are instead all using mutable data structures... I.e., they are programming with side-effects and loops (random access instead of recursion, even when ever element of an array/list needs to be accessed/processed).

No. What he's saying in that you should use the best data structure for the job. Your best bet would have been to use the Hashtbl module from the standard library, or if you wanted to stay in the purely applicative, the Map module (also in the standard library) would have been loads faster...

You are aware that there are more purely functional data structures (pdf) (OCaml implementations) than the list, don't you?

So... maybe you can re-write higher-order memoization code using more efficient data structures? I would love to see that code, and I'm sure the OCaml community would benefit from having that in their toolbox.

Here's a pretty neat example that uses arrays in a naive way, but you could certainly use, say, a map instead... And I'm pretty sure the OCaml community (by which I mean the people who would have helped you improve your code had you asked them) know about things like this.

I don't think I spread any falsehoods. I mean, my experiment was real, and the results are real, and the code is there for people to inspect and try on their own. I also talked in my /. post about OCaml code that is isomorphic to C being fast, but functional code perhaps not being fast.

Yes. And we inspected it, found it to be poorly written, and told you so. The "falsehood" here is that you claim that code written in a functional style is slow, when you really should have said "my code written in a naively functional style is slow". If I fill my gas tank with water, my car sure is slower than walking, therefore all cars are slower than walking... right?

Trust me... I am *dying* to use OCaml or Haskell for real-world programming. I have spent the past month or so exploring these languages and trying to apply them to real programming problems. Especially when shootout results showed that OCaml was sometimes faster than C, and when I discovered that OCaml was much faster than Hasell, I was really starting to think that OCaml was a possibility.

I put a link to tho OCaml mailing lists above. Use it. Ask questions of the list (you may want to start with the beginner's list). They can help you learn the language faster and better than google will.

However, the ONLY reason why I would want to use OCaml is to take advantage of the expressiveness of pure functional programmin

Okay... but here's my point: Every single example that shows how elegant Haskell and OCaml are uses lists. The 4-line Quicksort example for Haskell uses lists. All of the code that demonstrates easy reuse of functions and functions taken as arguments uses lists (like how easy it is to implement quite complicated algorithms using only map and filter, for example).

Or perhaps more correctly, "every single example that you've seen". For a real quick one, look at Jason Hickey's Intro to OCaml (pdf) and have a quick peek at his Red/Black tree implementation. Or even cooler (if you're into that sort of thing) is the ever famous One Day Compilers talk.

But what you're saying in #1 above is that in "production," speed-sensitive code, no one is using lists... this would mean that no one is using map, filter, or any other pieces of reusable primitive code. So, they are instead all using mutable data structures... I.e., they are programming with side-effects and loops (random access instead of recursion, even when ever element of an array/list needs to be accessed/processed).

No. What he's saying in that you should use the best data structure for the job. Your best bet would have been to use the Hashtbl module from the standard library, or if you wanted to stay in the purely applicative, the Map module (also in the standard library) would have been loads faster...

You are aware that there are more purely functional data structures (pdf) (OCaml implementations) than the list, don't you?

So... maybe you can re-write higher-order memoization code using more efficient data structures? I would love to see that code, and I'm sure the OCaml community would benefit from having that in their toolbox.

Here's a pretty neat example that uses arrays in a naive way, but you could certainly use, say, a map instead... And I'm pretty sure the OCaml community (by which I mean the people who would have helped you improve your code had you asked them) know about things like this.

I don't think I spread any falsehoods. I mean, my experiment was real, and the results are real, and the code is there for people to inspect and try on their own. I also talked in my /. post about OCaml code that is isomorphic to C being fast, but functional code perhaps not being fast.

Yes. And we inspected it, found it to be poorly written, and told you so. The "falsehood" here is that you claim that code written in a functional style is slow, when you really should have said "my code written in a naively functional style is slow". If I fill my gas tank with water, my car sure is slower than walking, therefore all cars are slower than walking... right?

Trust me... I am *dying* to use OCaml or Haskell for real-world programming. I have spent the past month or so exploring these languages and trying to apply them to real programming problems. Especially when shootout results showed that OCaml was sometimes faster than C, and when I discovered that OCaml was much faster than Hasell, I was really starting to think that OCaml was a possibility.

I put a link to tho OCaml mailing lists above. Use it. Ask questions of the list (you may want to start with the beginner's list). They can help you learn the language faster and better than google will.

However, the ONLY reason why I would want to use OCaml is to take advantage of the expressiveness of pure functional programmin

Okay... but here's my point: Every single example that shows how elegant Haskell and OCaml are uses lists. The 4-line Quicksort example for Haskell uses lists. All of the code that demonstrates easy reuse of functions and functions taken as arguments uses lists (like how easy it is to implement quite complicated algorithms using only map and filter, for example).

Or perhaps more correctly, "every single example that you've seen". For a real quick one, look at Jason Hickey's Intro to OCaml (pdf) and have a quick peek at his Red/Black tree implementation. Or even cooler (if you're into that sort of thing) is the ever famous One Day Compilers talk.

But what you're saying in #1 above is that in "production," speed-sensitive code, no one is using lists... this would mean that no one is using map, filter, or any other pieces of reusable primitive code. So, they are instead all using mutable data structures... I.e., they are programming with side-effects and loops (random access instead of recursion, even when ever element of an array/list needs to be accessed/processed).

No. What he's saying in that you should use the best data structure for the job. Your best bet would have been to use the Hashtbl module from the standard library, or if you wanted to stay in the purely applicative, the Map module (also in the standard library) would have been loads faster...

You are aware that there are more purely functional data structures (pdf) (OCaml implementations) than the list, don't you?

So... maybe you can re-write higher-order memoization code using more efficient data structures? I would love to see that code, and I'm sure the OCaml community would benefit from having that in their toolbox.

Here's a pretty neat example that uses arrays in a naive way, but you could certainly use, say, a map instead... And I'm pretty sure the OCaml community (by which I mean the people who would have helped you improve your code had you asked them) know about things like this.

I don't think I spread any falsehoods. I mean, my experiment was real, and the results are real, and the code is there for people to inspect and try on their own. I also talked in my /. post about OCaml code that is isomorphic to C being fast, but functional code perhaps not being fast.

Yes. And we inspected it, found it to be poorly written, and told you so. The "falsehood" here is that you claim that code written in a functional style is slow, when you really should have said "my code written in a naively functional style is slow". If I fill my gas tank with water, my car sure is slower than walking, therefore all cars are slower than walking... right?

Trust me... I am *dying* to use OCaml or Haskell for real-world programming. I have spent the past month or so exploring these languages and trying to apply them to real programming problems. Especially when shootout results showed that OCaml was sometimes faster than C, and when I discovered that OCaml was much faster than Hasell, I was really starting to think that OCaml was a possibility.

I put a link to tho OCaml mailing lists above. Use it. Ask questions of the list (you may want to start with the beginner's list). They can help you learn the language faster and better than google will.

However, the ONLY reason why I would want to use OCaml is to take advantage of the expressiveness of pure functional programmin

let rec length_aux len = function
[] -> len
| a::l -> length_aux (len + 1) l

let length l = length_aux 0 l

let hd = function
[] -> failwith "hd"
| a::l -> a

let tl = function
[] -> failwith "tl"
| a::l -> l

let rec nth l n =
match l with
[] -> failwith "nth"
| a::l ->
if n = 0 then a else
if n > 0 then nth l (n-1) else
invalid_arg "List.nth"

let append = (@)

let rec rev_append l1 l2 =
match l1 with
[] -> l2
| a :: l -> rev_append l (a :: l2)

let rev l = rev_append l []

let rec length_aux len = function
[] -> len
| a::l -> length_aux (len + 1) l

let length l = length_aux 0 l

let hd = function
[] -> failwith "hd"
| a::l -> a

let tl = function
[] -> failwith "tl"
| a::l -> l

let rec nth l n =
match l with
[] -> failwith "nth"
| a::l ->
if n = 0 then a else
if n > 0 then nth l (n-1) else
invalid_arg "List.nth"

let append = (@)

let rec rev_append l1 l2 =
match l1 with
[] -> l2
| a :: l -> rev_append l (a :: l2)

let rev l = rev_append l []

As you pointed out, Haskell doesn't support operator overloading, either, so be careful in what you are asking for--people may get the impression that you'd much prefer that to type classes, which are, I think, somewhat better (you seem to agree).

Anyway, I am afraid I don't know OCaml that well, but at a glance, this research looks pretty interesting (you might want to start with his Thesis).

As for your comments about Haskell, first, though you say Haskell is always evolving and OCaml is set in stone, I believe you have that a bit backwards. Haskell98 is officially frozen; while development on the language continues, it is all non-standard, so generally compiler-specific (e.g. the ghc extensions, etc). OCaml appears to be officially still in development, though, as I said before, I don't follow it enough to really know what that means.

And second, you comment that monads are tedius (I assume this is what you mean), and you are somewhat right. But there are, obviously, some really impressive benefits from using monads as well (i.e. try not to think of monads as something being shoved down your throat by mathematical pedants). If you continue to use Haskell, you will likely find some such uses (on the other hand, you are every bit correct about the performance of many Haskell programs, but programmer time costs more than CPU time). One that I found pretty impressive is the ability to implement a nondeterministic parser using monads to represent parse matches or non-matches--a case where monads don't just wrap I/O or other state, but acctually do something cool...

Show me one example where O'Caml beats C++.

ICFP contests:

2004 (ocaml 1st); 2003 (ocaml 1st); 2000 (ocaml 3rd, C++ 5th); >2001 (ocaml tied 3rd place with C);

Others winners: 1998 C derivative, 2002 python (I think C++ actually beat OCaml this year)

Show me one example where O'Caml beats C++.

Why not use the revised syntax then?

http://caml.inria.fr/pub/docs/tutorial-camlp4/tuto rial005.html

Yes, C++ takes bloody forever to compile (standard example: Mozilla). This is because C++ is a horrifically complex language, and uses textual inclusion of source code as a standard mechanism. For many applications, ocaml is a suitable replacement for C++. Your source code will be shorter, more correct, and compile much more quickly.

And what about GUI and other side effects? Debugging a program in which such side-effects are deeply interleaved with algorithmics can be tricky indeed, although smart timestamping from the debugger will reduce glitches. But if you don't know better than randomly mixing algo and front-end in the first place, then you'd better fix the programmer than the program...

French scientists are not allowed to write publications in any language other than French

I beg your pardon ??

It is true that French scientists - who happen to have a civil servant status - are often required to produce reports in French. I don't know where you got the idea that they are forbidden from publishing anything in English.

Another example: a few years ago, out of a sudden, the french government decreed that the word e-mail is to be forbidden and replaced with made-up "courriel".

Yeah, Heaven forbid that people speaking a different language try to create new words for new things instead of just adopting English ones !

BTW, the word "courriel" was coined by the Quebecois.

Thomas-

And Graham's thoughts on the Hindly-Milner type inference used in modern functional languages with REPLs (e.g. OCamlare...?

95% of the time you you type in no type annotations, and 4.99 of the other 5% of the time it's when you're using something like variant types. For the added safety (and other benefits, like making debugging with a REPL much easier) of the strong type system, Graham's position as stated above is greatly weakened.

The Caml language (pronounce "Camel") is missing.
Caml is a programming language, easy to learn, easy to use, and yet amazingly powerful.
It is developed and distributed by INRIA (the main French research institute for computer science), since 1984. It is freely available for Unix, PC or Macintosh.
There exist two flavors of Caml: Caml Light and Objective Caml. Caml Light is merely a subset of Objective Caml, especially designed for teaching and learning the art of programming. In addition to the Caml Light's core language, Objective Caml features a powerful modules system, full support to object-oriented paradigm, and an optimizing compiler.
More information here.

The Caml language (pronounce "Camel") is missing.
Caml is a programming language, easy to learn, easy to use, and yet amazingly powerful.
It is developed and distributed by INRIA (the main French research institute for computer science), since 1984. It is freely available for Unix, PC or Macintosh.
There exist two flavors of Caml: Caml Light and Objective Caml. Caml Light is merely a subset of Objective Caml, especially designed for teaching and learning the art of programming. In addition to the Caml Light's core language, Objective Caml features a powerful modules system, full support to object-oriented paradigm, and an optimizing compiler.
More information here.

... And, amusingly, IKEA has been a big user of Linux for years.

Ever peered at one of the monitors on one of IKEA's store computers? Even now, they seem to be running some weird amalgamation of X and Windows. One I saw seemed to have some Windows terminal program running in an exported window on X, and the Windows terminal program was connected to some mainframe-type system. Weird combination, but it appears to work... ;-)

And in California, all they would need to get the VIN is go here and insert the plate number. (I hope I'm wrong about this.)

You're not. I looked up the plates of an arbitrary car photo I found with a Google image search (license 2DHC336), and it returned the VIN.

I'd much rather use Skribe.

The first is treatment of concurrency based on join-calculus.

The second is type system for XML. There is a lot of research in CS for strongly-typed XML processing (check XDuce for one).

TFA actually does a good job of presenting most important concepts of those for people not quite familiar with undelying theory.

First of all, Windows does not have very efficient threads. OK, compared to Linux they might be good

Linux is no where close to scaling its threads up to 64 processors.

Unlike other implementations of Posix threads for Linux, LinuxThreads provides kernel-level threads: threads are created with the new clone() system call and all scheduling is done in the kernel.

The main strength of this approach is that it can take full advantage of multiprocessors. It also results in a simpler, more robust thread library, especially w.r.t. blocking system calls.

Oh, and if you think the latest implementation of Linux thread are slower, especially slower then MS Windows, you are an idiot. Here is are some test from IBM. Current Linux threads were spawning at more then 10,000 PER SECOND while MS Windows was spawning barely 6,000. Linux Thread performance, scroll down to the "pretty" graphs. Oh, and these numbers are higher then Solaris. Linux threads and Linux processes spawn _MUCH_ faster then the best MS has to offer and faster then Solaris.

"My father sent me to work programming in basic from textbooks when I was 4. I found this a wonderful thing, as I could make the computer do what I wanted. I learned syntax and other important elements of programming, and now as I write this, the computer has stuck with me ever since. This is why I'm a computer science major."

DrScheme. Yes, young people can pick it up easily.

Oh for those who like LaTex? Try the Scheme version

Is it really so hard to use tags?

Software radio or SDR - an intresting subject where mathematical formulas become radio.

See for a high level overview.

Good reading is Understanding digital Signal processing by Richard G. Lyons. Prentice Hall, 1st ed: ISBN 0201634678 (amazon.com, search). 2nd ed: ISBN 0-13-108989-7 (amazon.com, search)

VanuBose 's company Vanu Technology demonstrated a software radio based on an iPAQ with a digital radio "backpack", in May 2003. Here are some links:

Slashdot article

Linuxdevices.com

Vanu.com

Vanu.com

Here's a note on the future of software defined radio

Several relevant pointers available here

statistics:
R http://www.r-project.org/
WinBugs http://www.mrc-bsu.cam.ac.uk/bugs/winbugs/contents .shtml

symbolic mathematics:
Maxima http://maxima.sourceforge.net/

numerics:
Octave http://www.octave.org/
Scilab http://scilabsoft.inria.fr/
g95 (Fortran 95 compiler)http://www.g95.org/

I don't know how open the code is, but it is free (beer).

It may be overkill but Scilab http://scilabsoft.inria.fr/ is a very powerful math program. I can't even begin to list what it does. I don't know how open the code is, but it is free (beer). Comes with most large distros too.
Michael

Scilab might not be a bad choice either - http://scilabsoft.inria.fr/. It is available for both *nix and Windows, and is quite powerful.

Scilab http://scilabsoft.inria.fr/ is an open source clone of matlab available for both Linux and Windows. I use it almost daily. 99.9% of what you do in Matlab can be done in Scilab for free.

Setting the sort order explicitly doesn't bother me at all; what bothers me is needing to use parameterized modules, which looks like bloating your code just to get around the type system. What I would like is to simply pass a function that can be applied to the element type in the tree---but I don't know how.

The way you would do this in Lisp is to either pass in a comparison function or to use a generic function for comparison, which is close to what you're talking about doing in Haskell. I believe there's something similar in G'Caml, but I haven't seriously looked into it yet.

first class functions in a static language? This is like having mallable steel trusses? What is this trying to do again? If you want first class functions, you'll want a define-on-the-fly language as well.

You, sir, are either trolling or criminally ignorant.

Here is a statically typed, natively compiled language that provides fully first-class functions.

Here is another.

There are many others; those are just the most widely used.

I've been using Bigloo (from the same folks as OCaml) for Scheme. You might find it gives you a lot of what you want.

There's a bunch of good tutorials here. I learned everything I know about ocaml from there, in particular from Jason Hickey's, Richard Jones' and the OCaml manual. I spent a week learning that stuff and playing with it, and another week writing from scratch a rather non-trivial program that would have easily taken two months in C. I found ocaml astounding: nearly as fast as C, as compact and elegant as python (arguably more so, in fact).

Basically, if you can't write a complex FFT with a user-defined complex number type and have it work about as efficiently (in both space and time) as equivalent Fortran 90 or C++ code, then the language is not suitable for modern general-purpose applications.

I completely disagree.

1) What do you consider "about as efficiently?" A ten-second search turns up an FFT benchmark written by Xavier Leroy; he reports that it runs about 2/3 as fast as C code.

2) What the hell kind of "modern general-purpose application" needs to compute FFTs quickly? That's a highly specialized application.

3) If certain algorithms cannot be computed quickly in OCaml, just write them in C. Bindings to C functions are trivial to write. You want to do FFTs? It's already been done.

I'm not sure how you could refute the official objective caml license, which clearly states that runtime system and standard libraries are licensed under LGPL (to allow linking with commercial programs), and the compiler and tools are licensed under QPL, which allow you to distribute unmodified code as is, or your modification "in a form that is separate from the Software."

The example given in QPL is using patches, but I don't see why you can't fork the source, since it would still be "separate" (just don't call it Objective CAML, but something else). QPL does not say your modification has to be in the form of patches.

One solution that many of these languages are now taking is to target either the .NET framework or the JVM. For example, F# and SML.NET are two different projects from Microsoft Research aimed at producing ML-like compilers targeted at .NET. The Bigloo Scheme compiler now has an experimental .NET backend in addition to native code and JVM backends. There are also some Haskell compilers targetting the .NET now. If you look around, quite a few functional languages are beginning to support some combination of .NET and the JVM.

For many languages, this solves exactly the problem that you describe. The new language instantly gets the benefit of large, useful and well tested library. The language developers can focus on the design of their language and leave the hassle of building and maintaining the supporting run-time and library to someone else. Eventually they can add a more native-feeling system library layer over it, but targeting the .NET or JVM gets them off the ground right away.

There's a few quirks involved in shoehorning functional languages this way. As I recall, the JVM is a bit more difficult to compile functional languages to since it is really intended to run Java. .NET is a bit easier, though there are still some quirks. Many of those are known at this point, however, and there are even some libraries even to help work around them (e.g. the ILX SDK developed for F#.) I also think I recall something about the next update to MSIL addressing many of those quirks to simplify the development of functional language compilers.

OCaml's major problem is that, like every other functional language available today, the breadth of its standard library and third-party libraries is totally pathetic in comparison to the likes of Java and Python. The same limitation applies to Lisp, Scheme, Haskell, Erlang, etc.

I don't know; I've always been able to find libraries that I needed for Haskell; there are quite a few listed on the Haskell libraries page. It seemed to me, when I was evaluating OCaml, that a lack of libraries bindings or bindings to other language's libraries was not a problem. They've got quite a decent database of extensions at The Camel Humps

I'm mainly a Java and Ruby developer, though, so I may not have stressed tested the availability of Haskell libraries. Java doesn't use libraries; if somebody writes a third-party library for it, Sun re-implements it, poorly, and bundles it with the VM, which effectively kills the original, and often superior, library. And Ruby... well, you just create whatever bindings you need, dynamically, with 'dl'.

--- SER

Chinese teaches you about whatever dialect of Chinese you learned, and I believe a bit about Korean. Latin gives insight into French, Spanish, Italian, and a lot of English, plus a leg up in understanding legal terms, medical terminology, etc. (Although I'm sure some linguist could come around now and point out all of my errors...)

What's rec? What's l? What's h? What's t? What's fun? What's less? What's greater? It's not documented, and I don't want to read up on OCAML to find out that it isn't documented, either.

rec indicates that the function is recursive (something covered in section 1.1 of the OCaml manual). l, h, t, less, and greater are (prepare for shock and awe) variable names, representing the following values: l is the list being sorted, h is the head of that list, t is the tail of the list, less is the list of values that are less than the head of l and surprisingly greater is the list of values greater than (or equal to) h. If you have trouble telling what a variable is, it's no wonder Haskell befuddled you (Do you look at a function like let f x = x + 3 and ask, "What's x? What's 3?"). By the way, before you ask, List.partition is a function that partitions a list into two sublists according to some predicate. I'd apologize for it not being documented, but well... it is.

Certainly a fibbonnaci series computed in a loop runs faster than the equivalent recursive solution.

Well that certainly depends on whether you mean recursive in the sense of the process or in the sense of the procedure (see SICP if you don't know the difference. The difference in performance between a for loop and something like:

let fib n =
let rec fib_h a b n =
if n = 0 then b else fib_h (a + b) a (pred n) in
fib_h 1 0 n;;

Unless, of course we're talking about a memoized version. But if you want one, it's actually pretty damn easy to wrap a recursive function with a memoizing wrapper. By the way, do you really want to be talking about speed and efficiency in a thread about Perl?

Tree manipulation is generally a toy problem.

Tree manipulation is a toy problem? Last time I checked, trees (and heaps and treaps, and all sorts of other recursive data structures) are all over programming.

What's more, I can write recursive solutions in perl if I really have to.

And I can do imperative programming in OCaml if I really have to. Your point was what again?

We're programmers. We do need to understand that complex underbelly.

So you know all about the properties of the semiconductors making up your machine? You can tell me how to build a J/K filp-flop and a shift register? You know all about circuit layout optimization? The inner workings of a DVD burner? See, that's one of the nice things about programming. You only need to strip off a certain number of layers of abstraction to do your job well -- sometimes you need to go deeper, sometimes you don't need to go deep at all.

We often need to prove that we're using exactly the correct function, and that it operates in the smallest amount of time, using the fewest resources possible.

And so you're advocating Perl?!? It's nigh impossible to reason at all about imperative programs and prove them correct, but when you've got a language that essentially encourages willy-nilly programming styles (yes, I know you can code clean Perl, but it takes a lot more effort than other languages) and highly mutable state like Perl than pretty much all hope i

Chinese teaches you about whatever dialect of Chinese you learned, and I believe a bit about Korean. Latin gives insight into French, Spanish, Italian, and a lot of English, plus a leg up in understanding legal terms, medical terminology, etc. (Although I'm sure some linguist could come around now and point out all of my errors...)

What's rec? What's l? What's h? What's t? What's fun? What's less? What's greater? It's not documented, and I don't want to read up on OCAML to find out that it isn't documented, either.

rec indicates that the function is recursive (something covered in section 1.1 of the OCaml manual). l, h, t, less, and greater are (prepare for shock and awe) variable names, representing the following values: l is the list being sorted, h is the head of that list, t is the tail of the list, less is the list of values that are less than the head of l and surprisingly greater is the list of values greater than (or equal to) h. If you have trouble telling what a variable is, it's no wonder Haskell befuddled you (Do you look at a function like let f x = x + 3 and ask, "What's x? What's 3?"). By the way, before you ask, List.partition is a function that partitions a list into two sublists according to some predicate. I'd apologize for it not being documented, but well... it is.

Certainly a fibbonnaci series computed in a loop runs faster than the equivalent recursive solution.

Well that certainly depends on whether you mean recursive in the sense of the process or in the sense of the procedure (see SICP if you don't know the difference. The difference in performance between a for loop and something like:

let fib n =
let rec fib_h a b n =
if n = 0 then b else fib_h (a + b) a (pred n) in
fib_h 1 0 n;;

Unless, of course we're talking about a memoized version. But if you want one, it's actually pretty damn easy to wrap a recursive function with a memoizing wrapper. By the way, do you really want to be talking about speed and efficiency in a thread about Perl?

Tree manipulation is generally a toy problem.

Tree manipulation is a toy problem? Last time I checked, trees (and heaps and treaps, and all sorts of other recursive data structures) are all over programming.

What's more, I can write recursive solutions in perl if I really have to.

And I can do imperative programming in OCaml if I really have to. Your point was what again?

We're programmers. We do need to understand that complex underbelly.

So you know all about the properties of the semiconductors making up your machine? You can tell me how to build a J/K filp-flop and a shift register? You know all about circuit layout optimization? The inner workings of a DVD burner? See, that's one of the nice things about programming. You only need to strip off a certain number of layers of abstraction to do your job well -- sometimes you need to go deeper, sometimes you don't need to go deep at all.

We often need to prove that we're using exactly the correct function, and that it operates in the smallest amount of time, using the fewest resources possible.

And so you're advocating Perl?!? It's nigh impossible to reason at all about imperative programs and prove them correct, but when you've got a language that essentially encourages willy-nilly programming styles (yes, I know you can code clean Perl, but it takes a lot more effort than other languages) and highly mutable state like Perl than pretty much all hope i

And I know there's Camlp4 and MetaOCaml, but they're really too kludgy for my taste, though still better than the insanity that is C++ template metaprogramming. (Ick!)

[Stuff about lackluster optimization]

[Stuff about COCaml interface]

Offical Site (ocaml.org)

OCaml.org is NOT the official site. The official site is http://caml.inria.fr/.

It's worth mentioning a few other features that aren't as common in other languages. The main ones for me are structural subtyping (basically what Python types call "duck typing", but guaranteed sound at compile-time) and an excellent debugger with a "rewind" function letting you take your code back to an earlier state and try a different execution path.

The syntax is a bit odd at first, and knowing it is unlikely to get anyone a job, but it's a nice language to use for personal projects...

I played with OCaml for a good length of time, considering whether to make it my next language for everyday use. I should also preface things by mentioning that I'm into graphics and rendering; I need fairly heavy duty numeric performance. I've also been thinking a lot about what would be my perfect language, so this has been on my mind of late - I've been reading up on Programming Language Theory papers and texts and contemplating drafting my own language spec and trying to bootstrap a compiler.

OCaml annoys me slightly because it seems so tantalizingly close to what I'm looking for but falls just short. For one, I wish it had better support for generative programing. Sure, for template like stuff you can immitate that to some extent through the polymorphism, but because it has to be generic, it still doesn't work out performance-wise. Look at the kind of stuff they can do with Blitz++. And I know there's Camlp4 and MetaOCaml, but they're really too kludgy for my taste, though still better than the insanity that is C++ template metaprogramming. (Ick!) The model that I really like is the macro systems in Lisp or Scheme. That would require a Lisp-like syntax to work, but I'm cool with that.

The other thing that bugs me a bit is that the compiler seems fairly simple in regards to optimization passes. When I've looked at assembly output from it, even with all optimizations turned on, I was surprised to see that it doesn't seem to do common subexpression elimination or strength reduction, like a common C compiler could do for you. I realize that OCaml is more functional, which constrains the compiler a bit, but there are compilers for other functional languages that manage to do flow graph analysis and optimization. (e.g. Stalin for Scheme) This lack is dissapointing in a higher level, more declarative style language like OCaml.

Finally, one other thing is that while the foreign-function interface to C is better than many other functional languages, I wish it were still better. With OCaml, it seems like you'd still need a small library in C as a shim to interface between the two languages. It would be nice if you could simply declare a function's signature, mark it as an external C function and link the library in. To deal with garbage collection, I'd borrow something like the "pin" construction from C#. I think C# and the .Net framework have a really nice model for FFI.

Of course, if you don't need such heavy duty performance, OCaml's still a great system and a fair sight better than many other functional language systems. But it's not a panacea for everything.

One more thing: if you use (X)Emacs, be sure to have a look at Tuareg Mode.

I played with OCaml for a good length of time, considering whether to make it my next language for everyday use. I should also preface things by mentioning that I'm into graphics and rendering; I need fairly heavy duty numeric performance. I've also been thinking a lot about what would be my perfect language, so this has been on my mind of late - I've been reading up on Programming Language Theory papers and texts and contemplating drafting my own language spec and trying to bootstrap a compiler.

OCaml annoys me slightly because it seems so tantalizingly close to what I'm looking for but falls just short. For one, I wish it had better support for generative programing. Sure, for template like stuff you can immitate that to some extent through the polymorphism, but because it has to be generic, it still doesn't work out performance-wise. Look at the kind of stuff they can do with Blitz++. And I know there's Camlp4 and MetaOCaml, but they're really too kludgy for my taste, though still better than the insanity that is C++ template metaprogramming. (Ick!) The model that I really like is the macro systems in Lisp or Scheme. That would require a Lisp-like syntax to work, but I'm cool with that.

The other thing that bugs me a bit is that the compiler seems fairly simple in regards to optimization passes. When I've looked at assembly output from it, even with all optimizations turned on, I was surprised to see that it doesn't seem to do common subexpression elimination or strength reduction, like a common C compiler could do for you. I realize that OCaml is more functional, which constrains the compiler a bit, but there are compilers for other functional languages that manage to do flow graph analysis and optimization. (e.g. Stalin for Scheme) This lack is dissapointing in a higher level, more declarative style language like OCaml.

Finally, one other thing is that while the foreign-function interface to C is better than many other functional languages, I wish it were still better. With OCaml, it seems like you'd still need a small library in C as a shim to interface between the two languages. It would be nice if you could simply declare a function's signature, mark it as an external C function and link the library in. To deal with garbage collection, I'd borrow something like the "pin" construction from C#. I think C# and the .Net framework have a really nice model for FFI.

Of course, if you don't need such heavy duty performance, OCaml's still a great system and a fair sight better than many other functional language systems. But it's not a panacea for everything.

One more thing: if you use (X)Emacs, be sure to have a look at Tuareg Mode.

let hello foo = "Hello, " ^ foo

let gimme_a_one x = 1;;

Personally, when I count words in LaTeX I avoid the .dvi step. I use either the simple untex or the prettier hevea to go from LaTeX to plain text. This avoids the problem of page numbers and references, though it has some other issues.

For Lisp you could use ACL2. For Java you could use JML , together with Krakatoa, Why (which could also be used to program the solution) and Coq. For all the other languages that appear in the solutions list I think you're on your own.

So others can have fun slashdotting other technologies, here are some websites. There are probably others, but this should keep those who do really want to move away from TCP happy.

• Actual sourcecode to transmit binaries by multicast
  
• IETF Reliable Multicast Transport - Charter + RFCs
  
• Introduction to Multicasting (a little old, doesn't cover things like IGMPv3)
  
• Lightweight Reliable Multicast Protocol
  
• Microsoft's Reliable Multicast
  
• SUN's Reliable Multicast system
  
• Navy Research Laboratory implementation
  
• Scalable Reliable Multicast
  
• Cooperative Reliable Multicast
  
• Reliable Multicast for Wireless environments
  
• Selectively Reliable Multicast
  

For experienced programmers, learning a new language is not hard, especially if it is similar to what you already know. Python is similar to what you already know.

Any given problem could likely be solved in almost any given modern language. I could write an IMAP client in C, a Web server in Java, or a database client in C++.

In Python, you can write correct solutions to many network-related problems with astonishingly little code. And by correct, I mean with error detection everywhere (and handling where appropriate), safe handling of strings (not an issue in Python usually, but a constant problem in C), no deadlock conditions, etc. And what's more, those solutions are usually readable. There are some examples in the book of that. There's a simple FTP mirroring example in the book. 75 lines of code (excluding blank lines).

Now, I could have written it in C, Perl, Haskell, OCaml, Java, Lisp, Pascal, whatever. That's absolutely true. Most of those would not have let me do it in 75 lines of readable code using solely a component that comes out of the box with the language.

Sometimes, the time it takes you to learn a new language and develop a correct, effective solution in that language is less than the time it takes you to develop an incorrect solution in another. Sometimes not, and it's better to stick to the language you know. My point is that you should not always assume this is best.

How about another example. A little keyboard interaction program. Compare:

Python:

from sys import stdin
print "Who are you?"
name = stdin.readline().strip()
print "I'm glad to meet you, %s." % name

Haskell:

main = interact ((++) "Who are you?\n" .
(++) "I'm glad to meet you, " .
((++) `flip` ".\n") . head . lines )

Java:

import java.io.*;

class Hello {
public static void main (String[] args) throws IOException {
BufferedReader ki = new BufferedReader(new
InputStreamReader(System.in));

System.out.println("Who are you?");
String name = ki.readLine();
System.out.println("I'm glad to meet you, " + name + ".");
}
}

Which do you think makes it easiest to interact with the user? I'd have to give the award to Python or Haskell. The Haskell example is a very different one from what you may be used to (hint: ++ is the concatenation operator), as it relies on the lazy and functional nature of the language, but it nonetheless is a concept that scales to incredibly powerful things.

Don't limit yourself by what language you prefer. Prefer a language by what problem you must solve.

(Sorry, it looks like /. stripped the indentation from these examples)

The Virtual Virtual Machine is, if I understand correctly, a virtual machine to build virtual machines.

Other tools which I have come across, but haven't really worked with: Axiom (symbolic computations, CAS); Scigraphica (graphing); opendx (data explorer + visualization).

I've actually never really used R (by the time I came across it, I was done with my physics labs), so I can't really compare any of the others to it. But it definitely looks like one of the tools that I should add to my suite.

Several interesting projects in that area exist among which the CImg library (found here) which has some interesting demos. A similar (but different) lib is being included in the Gimp. I think both will likely end up in it eventually.

So yes, you can add stuff that wasn't there to begin with by interpolating with what's already there. You may not always get what you expect though (and it still isn't as good as the version featured in MovieOS(TM)).

Xavier Leroy for the OCAML system and the Linux's Posix Threads.

Suerte :).